Skip to content
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

Open
wants to merge 43 commits into
base: master
Choose a base branch
from

Conversation

alexprudhomme
Copy link
Contributor

@alexprudhomme alexprudhomme commented Sep 20, 2024

louis-bompart and others added 30 commits September 19, 2024 19:09
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"
```
@fbeaudoincoveo fbeaudoincoveo marked this pull request as ready for review September 26, 2024 14:45
@fbeaudoincoveo fbeaudoincoveo requested review from a team as code owners September 26, 2024 14:45
@fbeaudoincoveo fbeaudoincoveo changed the title test: add package compatibility tests using publint and are the types wrong test: add package compatibility tests using publint Sep 26, 2024
Copy link
Contributor Author

@alexprudhomme alexprudhomme left a 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);

@fbeaudoincoveo
Copy link
Contributor

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.

@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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants