-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test: add package compatibility tests using publint #4446
Conversation
Co-authored-by: Alex Prudhomme <[email protected]>
This reverts commit 480b5bb.
All errors are fixed. Warnings left that I cant fix : 1. The types errors for commonJS are not urgent 2. I can't find how to tell stencil to generate commonjs files as .cjs instead of .js ``` npx publint ./node_modules/@coveo/atomic-react @coveo/atomic-react lint results: Warnings: 1. pkg.exports["."].types types is interpreted as ESM when resolving with the "require" condition. This causes the types to only work when dynamically importing the package, even though the package exports CJS. Consider splitting out two "types" conditions for "import" and "require", and use the .cts extension, e.g. pkg.exports["."].require.types: "./dist/index.d.cts" npx publint ./node_modules/@coveo/atomic @coveo/atomic lint results: Warnings: 1. pkg.main is dist/index.cjs.js and is written in CJS, but is interpreted as ESM. Consider using the .cjs extension, e.g. dist/index.cjs.cjs 3. pkg.exports["."].require is ./dist/index.cjs.js and is written in CJS, but is interpreted as ESM. Consider using the .cjs extension, e.g. ./dist/index.cjs.cjs 4. pkg.exports["."].types types is interpreted as ESM when resolving with the "require" condition. This causes the types to only work when dynamically importing the package, even though the package exports CJS. Consider splitting out two "types" conditions for "import" and "require", and use the .cts extension, e.g. pkg.exports["."].require.types: "./dist/types/index.d.cts" 5. pkg.exports["./loader"].import is ./loader/index.js and is written in ESM, but is interpreted as CJS. Consider using the .mjs extension, e.g. ./loader/index.mjs npx publint ./node_modules/@coveo/headless @coveo/headless lint results: Warnings: 1. pkg.exports["."].types types is interpreted as ESM when resolving with the "require" condition. This causes the types to only work when dynamically importing the package, even though the package exports CJS. Consider splitting out two "types" conditions for "import" and "require", and use the .cts extension, e.g. pkg.exports["."].require.types: "./dist/definitions/index.d.cts" ```
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was able to make a script with the zx library to test attw as well. In this one, I am testing headless and filtering out the FalseESM errors. Let me know if you think we should add this.
import {$} from 'zx';
interface Problem {
kind: string;
resolutionKind?: string;
}
await $({
nothrow: true,
})`npx attw --pack packages/headless --format json > .attw.json`;
const output = await $`cat .attw.json`;
await $`rm .attw.json`;
const json = JSON.parse(output.stdout);
json.analysis.problems = json.analysis.problems.filter(
(problem: Problem) => problem.kind !== 'FalseESM'
);
if (!json.analysis.problems || json.analysis.problems.length === 0) {
console.log('No errors found');
process.exit(0);
}
if (
json.analysis.problems.every(
(problem: Problem) => problem.resolutionKind === 'node10 '
)
) {
console.log("Only found node10 or problems, which we don't care about");
process.exit(0);
}
if (
json.analysis.problems.every((problem: Problem) => problem.kind === 'warning')
)
console.log('Errors found');
console.log(json.analysis.problems);
process.exit(1);
@alexprudhomme as discussed in person, I don't think we should run attw checks in our CI until our packages are clean enough that we aren't forced to filter out "false" positives all over the place in the attw report. Hopefully by then the attw CLI will have evolved to be more CI-friendly, or better yet they'll have released an npm library that does what we need. |
https://coveord.atlassian.net/browse/KIT-3596