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

[tooling] retire CJS for libraries #3324

Closed
wants to merge 15 commits into from
Closed

[tooling] retire CJS for libraries #3324

wants to merge 15 commits into from

Conversation

acao
Copy link
Member

@acao acao commented Jul 5, 2023

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 unneeded commonjs related config and tools for libraries
  • leaves the build directory as esm for now, for legacy import support? what do we think of this choice? or should we standardize on dist? I only change this for codemirror-graphql, but this keeps monaco-graphql/esm imports intact. if only imports key in package.json accepted * 😢
  • simplifies the project references build
  • if you're using graphql-lsp, upgrade
  • transparently builds all packages with a build script in order of dependency

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

After this:

  • turbopack
  • drop build-bundles?
  • targeted dev scripts

@changeset-bot
Copy link

changeset-bot bot commented Jul 5, 2023

🦋 Changeset detected

Latest commit: 60d2a40

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 11 packages
Name Type
codemirror-graphql Major
graphql-language-service Major
graphql-language-service-cli Major
graphql-language-service-server Major
monaco-graphql Major
cm6-graphql Minor
@graphiql/react Minor
@graphiql/toolkit Minor
graphiql Patch
vscode-graphql Patch
@graphiql/plugin-explorer Major

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

@acao acao added the tooling label Jul 5, 2023
@acao acao changed the title retire CJS for libraries [tooling] retire CJS for libraries Jul 5, 2023
@github-actions
Copy link
Contributor

github-actions bot commented Jul 5, 2023

The latest changes of this PR are available as canary in npm (based on the declared changesets):

@acao acao force-pushed the retire-cjs branch 6 times, most recently from d1fce1c to c85ec08 Compare July 5, 2023 19:43
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
@dimaMachina
Copy link
Collaborator

dimaMachina commented Jul 6, 2023

or should we standardize on dist?

I prefer dist, also you can add type: module in package.json to avoid mjs extensions

@acao
Copy link
Member Author

acao commented Jul 6, 2023

@B2o5T it seems to work fine without mjs extensions

why introduce another breaking change when we've already documented monaco-graphql/esm everywhere?

@acao
Copy link
Member Author

acao commented Jul 6, 2023

@B2o5T I agree with your point that dist makes more sense... and while we are making breaking changes and bumping versions... we might as well document this in the changelog and examples

we will need to make a PR to the vite monaco plugin to update their docs

@dimaMachina
Copy link
Collaborator

@acao it’s per this recommendation https://gist.github.com/sindresorhus/a39789f98801d908bbc7ff3ecc99d99c#how-can-i-move-my-commonjs-project-to-esm

and about monaco-graphql - it's already a major release so we could introduce breaking changes, also I would keep only the following exports:

  • monaco-graphql with initialize mode, not ugly monaco-graphql/esm/initializeMode
  • some exports for workers

so it simplifies things without monaco-graphql/{dist,esm}/something

Also, I would setup this rule https://github.com/sindresorhus/eslint-plugin-unicorn/blob/main/docs/rules/filename-case.md for consistency kebab-case filenames that we use in supported The Guild projects

and please hold this PR to merge until I approve it

@acao
Copy link
Member Author

acao commented Jul 6, 2023

already one step ahead 😆
image

@acao
Copy link
Member Author

acao commented Jul 6, 2023

I will get vitest working again, and make a few more tweaks, this is almost ready for a final review!

@acao
Copy link
Member Author

acao commented Jul 6, 2023

adding "type": "module" will take some more time, and will require converting a bunch of scripts and configs from require to import, I will have to come to that later. this will not be merged without much more review don't worry, haha

@acao
Copy link
Member Author

acao commented Jul 6, 2023

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 typings directory now when being imported

image

which is why this vitest is failing

image

I'm worried this test will be flaky as monaco-editor changes, is there maybe a better way to test? maybe ensure it has less than n modules?

@dimaMachina
Copy link
Collaborator

dimaMachina commented Jul 6, 2023

and will require converting a bunch of scripts and configs from require to import

you can temporarily renames their extension to cjs to avoid such as convertion

@acao
Copy link
Member Author

acao commented Jul 6, 2023

@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 esm conversion

@dimaMachina
Copy link
Collaborator

Also tests fail with the following error

AssertionError: expected '✓ 969 modules transformed.' to include '✓ 1092 modules transformed.

nice 👍 we have fewer converted modules 😂

@acao
Copy link
Member Author

acao commented Jul 6, 2023

@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 monaco-graphql/dist/typings/monaco-editor.d.ts is not being picked up. the branch in it's current state fails the example builds

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 /monaco or /webpack path to demonstrate the example build output on netlify. it's slower but worth it. this was what build-demo used to do

@dimaMachina
Copy link
Collaborator

maybe ensure it has less than n modules?

I guess it is good to keep the exact number of dependencies, I think we'll adjust this number very rarely when vite version changes or such as this migration

@dimaMachina
Copy link
Collaborator

I think this may be caused by a regression where

I can take a look later this week, currently on vacation

@acao
Copy link
Member Author

acao commented Jul 6, 2023

@B2o5T no worries, I will figure it out! enjoy your holiday

@acao
Copy link
Member Author

acao commented Jul 6, 2023

I guess it is good to keep the exact number of dependencies, I think we'll adjust this number very rarely when vite version changes or such as this migration

This is what I'm worried about. This can be caused by either changes to vite or monaco-editor, and as a rule of thumb, I prefer to not write tests that test internal details of third party dependencies. I still think less than n will be more ideal, otherwise this might frustrate contributors as just small patch resolution changes could break this

@acao
Copy link
Member Author

acao commented Jul 6, 2023

@B2o5T ah i found the issue, had overlooked your script that patches types in renaming from esm to dist paths

"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"
Copy link
Collaborator

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?

Copy link
Member Author

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

@acao
Copy link
Member Author

acao commented Jul 7, 2023

@B2o5T i think this is good to merge now, and then your type": "module" effort can be a follow up PR, just to make the effort more manageable and scoped

@@ -6,7 +6,6 @@
"url": "https://github.com/graphql/graphiql",
"directory": "packages/graphiql-plugin-explorer"
},
"main": "dist/index.js",
Copy link
Collaborator

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

@dimaMachina
Copy link
Collaborator

@B2o5T i think this is good to merge now, and then your type": "module" effort can be a follow up PR, just to make the effort more manageable and scoped

Please wait for merge such as big PR

  1. you can always point your future work on this target branch
  2. I am not sure about graphiql react projects if you still bundle cjs or not, or what you decided
  3. I wanna polish exports for other packages to be true esm
  4. You can’t merge asap such as big changes in 2 days, I didn't review/tested a lot of things, no reasons for rush

@acao
Copy link
Member Author

acao commented Jul 7, 2023

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:

  1. complete & merge this PR that retires cjs for libraries, and simplifies the build tooling
  2. complete & merge make monaco-graphql true esm with "type": "module" and "exports" field, simplify it's exports #3327 and other efforts to migrate to full "type": "module" as an additional effort, instead of merging into this branch
  3. merge several other graphiql related efforts
  4. release

Overall, I think a more gradual approach to these iterations before next release is best

@acao
Copy link
Member Author

acao commented Jul 8, 2023

just to clarify @B2o5T, the purpose of this PR is not to move the whole monorepo to type: module. it is just to remove CJS exports for libraries, but not for consuming packages.

the effort of moving to "type": "module" is much greater and not required for this, as we can see with vite and webpack (including next js) happily consuming the esm only exports

the effort to move the repo to use esm only will require migration away from jest which does not support type: module, and changes to many files and tooling. these tooling changes are not required to only publish esm, despite how nonsensical it seems to use cjs to publish esm only libraries, this is sufficient for our users. the rest of the tooling migration will happen, but it's not the greatest priority right now.

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 "type": "modules" can happen seperately, as it is not required anymore by bundlers, unlike when sindre published that gist

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!

@acao
Copy link
Member Author

acao commented Aug 17, 2023

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.

@acao acao closed this Aug 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Development

Successfully merging this pull request may close these issues.

2 participants