Use .mjs extension for esm files#453
Conversation
Codecov Report
@@ Coverage Diff @@
## next #453 +/- ##
=========================================
Coverage 100.00% 100.00%
=========================================
Files 26 26
Lines 624 624
Branches 231 231
=========================================
Hits 624 624
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
|
Hi @gnapse, @sheremet-va, how's this look? |
|
Any feedback on this? |
rollup.config.js
Outdated
| index: 'src/index.js', | ||
| matchers: 'src/matchers.js', | ||
| }, | ||
| input: 'src/index.js', |
There was a problem hiding this comment.
Maybe it's better to provide an array for an input? So rollup can share code between files, otherwise matchers are duplicated.
There was a problem hiding this comment.
I'm not terribly familiar with rollup. How can I specify an array for input, when each one should have a specific different output?
There was a problem hiding this comment.
There is an example in Vitest repo: https://github.com/vitest-dev/vitest/blob/main/packages/vitest/rollup.config.js
You will need two entries, something like this:
export default [
{
input: entries,
output: {
dir: 'dist',
entryFileNames: '[name].mjs',
format: 'esm'
}
},
{
input: entries,
output: {
dir: 'dist',
entryFileNames: '[name].js',
format: 'cjs'
}
}
]
sheremet-va
left a comment
There was a problem hiding this comment.
Rollup now produces .js file with ESM content alongside correct .mjs file 😞
This file should be generated, so you don't have double code for /index and /matchers entry points.
I've added two possible solutions.
| input: entries, | ||
| output: { | ||
| dir: 'dist', | ||
| entryFileNames: '[name].mjs', |
There was a problem hiding this comment.
You can add chunkFileNames: '[name]-[hash].mjs', so chunks will also have correct filepath.
You can also add preserveModules: true, then rollup will not generate "chunks", it will have the same file structure as your source code.
I guess the first solution is closest to how it was, so 😄
There was a problem hiding this comment.
Good eye, thanks for catching that. I've taken your first suggestion, and mirrored it on the .js as well, just for consistency / to be explicit.
|
It works for me if I add the I don't work directly in node.js much, and espeically not with esm, but I do know I've needed to add this flag in the past. Is that not what you normally do? |
Well, it will be removed when Loader APIs will be finalized. I guess the problem is the other package that doesn't define |
This was previously handled as a file in the root of the project that redirected to the built index file. This change removes a layer of indirection by removing src/extend-expect, and using exports to point to the index file rather than using a real file in the project root.
|
Boy, ESM in node is kind of a PITA isn't it? lol. I added extensions / index.js, and also handled a file that I guess I had missed previously, extend-expect.js. I think using exports like this will work, but I'm not sure if I need the extension in the export map, or not. |
Yes, ESM<->CJS is a crime against humanity 😢
If you want people to import |
|
I see that everything else is working fine. But I thought you should know: import '@testing-library/jest-dom/extend-expect' // doesn't work
import '@testing-library/jest-dom/extend-expect.js' // works
const def = require('@testing-library/jest-dom/extend-expect') // doesn't work |
|
I think it might be a good idea to add a test for simply importing |
|
@gnapse @nickmccurdy what is the purpose of |
|
I assume it's just there for back compatibility. I agree that we probably don't need to keep it around for the next major (as long as we move the one-line implementation back to |
|
@nickmccurdy, done, thanks. I believe this is ready for review. |
|
@nickmccurdy @gnapse Hi, what are your thoughts on merging this and cutting a beta soon? |
|
Hi, friendly ping that I think this is ready to go. :) |
|
Hi, it's a bit of a shame that a breaking change was released without this PR and the related change (#438) to build and publish ESM. Was there a reason not to include them? Is another breaking change on the horizon? @nickmccurdy @gnapse @kentcdodds. 🙏 |
|
Sorry, there's a skeleton crew maintaining this project. That's why this wasn't merged. I'm afraid I only have the bandwidth to work on things that directly impact my own work. |
|
OK, thanks for responding. I only pinged you because I saw you were involved recently in the latest breaking release, and I'm a bit surprised that you're not using jest-dom and/or esm in your latest work. At any rate, I'm creating a new PR on top of the latest changes in |
|
I am actually, but with vitest and I don't think I've had issues. I'm going to look at it again in the future and if this fixes things for me then I may merge your other PR unless another maintainer steps up before I get to it |
|
@IanVS I think dual-publishing ESM/CJS could (and should?) be done in a non-breaking way, especially now that we've already done one breaking change that is creating some confusion amongst users (😅). |
|
Shouldn't this be reopened so #519 can close it? I'm not seeing |
|
@nickmccurdy This isn't an issue, it's a PR that I've decided to abandon and re-implement in #519. It can be re-opened if you'd like, but I don't think it should be reviewed/merged, so I was trying to keep things clean. |
|
You're right, I got mixed up when reviewing other notifications here. |
What:
This uses
.mjsfor esm files being exported from the package, since the package itself is not"type": "module". I also marked it as explicitly"type": "commonjs"for good measure.Also, I added a step to clean out the
distdirectory before each build.And combined the
dist/esmanddist/cjsdirectories, since now the files use different extensions.Why:
#437 (comment)
How:
Adjusted the rollup config
Checklist:
I've opened this against the
nextbranch, so that an alpha/beta version can be released.