-
Notifications
You must be signed in to change notification settings - Fork 1.7k
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
[tooling] retire CJS for libraries #3324
Conversation
🦋 Changeset detectedLatest commit: 60d2a40 The changes in this PR will be included in the next version bump. This PR includes changesets to release 11 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
The latest changes of this PR are available as canary in npm (based on the declared |
d1fce1c
to
c85ec08
Compare
It's 2023 and we don't need commonjs anymore. `graphql-js` will drop cjs for 16 This PR: - removes all `main` entrypoints - removes any commonjs related config and tools for libraries - leaves the build directory as `esm` for now, for legacy import support - simplifies the project references build - if you're using `graphql-lsp`, upgrade CJS still exists for: - vscode projects because vscode requires commonjs targer -`@graphiql/react` and `graphiql`, where legacy consumers may need them - TODO i think we will need it for cm6-graphql still for tests
I prefer |
@B2o5T it seems to work fine without mjs extensions why introduce another breaking change when we've already documented |
@B2o5T I agree with your point that we will need to make a PR to the vite monaco plugin to update their docs |
@acao it’s per this recommendation https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c#how-can-i-move-my-commonjs-project-to-esm and about
so it simplifies things without Also, I would setup this rule https://github.com/sindresorhus/eslint-plugin-unicorn/blob/main/docs/rules/filename-case.md for consistency and please hold this PR to merge until I approve it |
I will get vitest working again, and make a few more tweaks, this is almost ready for a final review! |
adding |
We will also need to figure out why this effort regressed before this can have the final review. it doesn't seem to be picking up the which is why this vitest is failing I'm worried this test will be flaky as |
you can temporarily renames their extension to |
@B2o5T indeed, but the jest side of things will be tricky, I will need to spend a few more days on this to finish the |
Also tests fail with the following error AssertionError: expected '✓ 969 modules transformed.' to include '✓ 1092 modules transformed. nice 👍 we have fewer converted modules 😂 |
@B2o5T haha nice! thus why i suggest using the "less than" approach suggested in the comment above. it seems github comments are slow for us today 😆 I think this may be caused by a regression where Speaking of, I'm considering whether we should make the example monaco build and one of the graphiql examples part of the netlify build again. This allowed us to validate consuming types previously, and then we had a |
I guess it is good to keep the exact number of dependencies, I think we'll adjust this number very rarely when |
I can take a look later this week, currently on vacation |
@B2o5T no worries, I will figure it out! enjoy your holiday |
This is what I'm worried about. This can be caused by either changes to |
@B2o5T ah i found the issue, had overlooked your script that patches types in renaming from |
"types": "./types/index.d.ts" | ||
}, | ||
"./font/roboto.css": "./font/roboto.css", | ||
"./font/fira-code.css": "./font/fira-code.css", | ||
"./dist/style.css": "./dist/style.css" |
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 guess it worked well before?
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.
it did, but this didnt work with webpack-cli serve
@B2o5T i think this is good to merge now, and then your |
@@ -6,7 +6,6 @@ | |||
"url": "https://github.com/graphql/graphiql", | |||
"directory": "packages/graphiql-plugin-explorer" | |||
}, | |||
"main": "dist/index.js", |
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.
This is needed, we still export cjs
Please wait for merge such as big PR
|
yes we can wait and fine tune it, and I would not release until all of these PRs are complete, but what I'm pointing out is that #3327 can wait until this is merged, because of we merge #3327 into this branch it will be very complicated When everything is ready, it can go like this:
Overall, I think a more gradual approach to these iterations before next release is best |
just to clarify @B2o5T, the purpose of this PR is not to move the whole monorepo to the effort of moving to the effort to move the repo to use esm only will require migration away from jest which does not support I'm trying to keep these PRs small, towards simplifying the repo tooling so we can make other improvements. As I mention in the last comment, the effort to move monaco-graphql to sorry this wasn't clear when this PR began, and now that I've seen the effort involved with more experiments today, I just want to draw a clear line of the scope here! |
I've learned from shipping other libraries to webpack consumers that commonjs exports are still required, so this is probably a bad idea. type: module is one thing, but dropping main and commonjs exports is another. |
It's 2023 and we don't need commonjs anymore.
graphql-js
will drop cjs for 16This PR:
main
entrypointsesm
for now, for legacy import support? what do we think of this choice? or should we standardize ondist
? I only change this forcodemirror-graphql
, but this keepsmonaco-graphql/esm
imports intact. if onlyimports
key inpackage.json
accepted*
😢graphql-lsp
, upgradebuild
script in order of dependencyCJS still exists for:
@graphiql/react
andgraphiql
, where legacy consumers may need themAfter this:
build-bundles
?dev
scripts