-
Notifications
You must be signed in to change notification settings - Fork 43
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
fix(build): switch to esbuild and tsc from pika #345
Conversation
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.
🎉
Don't forget to mark all type imports and exports |
I've seen this causing a few times. Do you know if we can somehow add a CI check to make sure we don't miss these in future? |
@wolfy1339 I believe I've done this correctly now; please take another look! @gr2m we could probably use something like this eslint rule. Without taking an extra dependency, perhaps it'd be better to use |
yeah I would like to avoid adding eslint
|
I agree that the typescript build option looks good. However I'm not sure if it will have an impact since esbuild doesn't use typescript to compile. |
👍 on adding the build flag; I've done so in the latest commit. When the type keyword is removed from imports (here for example), the
|
That's great! I'd add it as an option to https://github.com/octokit/tsconfig and maybe release it as a breaking change so that the different packages don't suddenly start breaking. We can then address all type import errors like show in your comment as we update to the new breaking version of |
While we're at it, we should move the options that are common across the repos to |
That doesn't catch the ones which aren't types but are used as types, like when using a class for the type of a parameter in a function |
@gr2m that seems reasonable! I've created octokit/tsconfig#15 to do so. Once that PR is merged and released, I can update all the in-flight pika removal PRs to bump octokit/tsconfig versions as well.
@wolfy1339 if you can find a good way to do this, please let me know and I can help roll that out as well! Thanks for all the thoughts so far. |
Some other options that may be reasonable to move to octokit/tsconfig are: "compilerOptions": {
"esModuleInterop": true,
"declaration": true,
"emitDeclarationOnly": true,
"sourceMap": true,
},
"include": ["src/**/*"] Do either of you have thoughts on these or others before I add them to octokit/tsconfig? |
Note that as of 9a3587f, tests are failing in Node 16 with errors like:
I've resolved these instances by using the CommonJS syntax However, we're also getting an issue in index.ts:
We could use an intermediary object in exports, though that would be a breaking change for consumers. Switching to ESM would be an option, though that's a whole other effort we've been postponing for some time. Are there other options I'm missing here to export this correctly? |
I think we can add a tsconfig just for tests that disables that option |
I'm picturing changing ...
"scripts": {
"build": "node scripts/build.mjs && tsc -p tsconfig.json",
"test": "node scripts/build.mjs && tsc -p tsconfig.test.json && jest --coverage",
... I don't love the idea of splitting the files but it's probably better than avoiding the compiler option entirely, especially with how easy it is (for me) to forget about type exports. Is that also what you're picturing? |
You don't need to change the scripts at all. |
@wolfy1339 thanks for the help! It's now done. I've also bumped the major version of octokit/tsconfig and removed the explicit specification of |
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.
Would it be wise to move it into the test directory?
As done in @octokit/webhooks
:
https://github.com/octokit/webhooks.js/blob/bc0ab962cb6218b6714c594a4b1c16ec8acbb707/tsconfig.json
tsconfig.test.json
Outdated
"sourceMap": true, | ||
"verbatimModuleSyntax": false | ||
}, | ||
"include": ["src/**/*"] |
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.
"include": ["src/**/*"] | |
"include": ["test/**/*"] |
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 one I'm less sure about.
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 don't think we should take this: then the tsconfig would only apply to the single test file, not the source code. Perhaps include
should be something like **/*
if we want to include both the test file(s) and the source code in the test tsconfig.
Co-authored-by: wolfy1339 <[email protected]>
Good call! Done. |
Once merged, any reservations to me rolling out the pattern introduced on this PR to the other octokit modules using pika? |
🎉 This PR is included in version 3.0.4 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Replicating octokit/request.js#584 to another repo.
Pika has been deprecated for a while now, and the project has now been archived, and because of that the released npm package is missing most of the files generated by the build step.
Uses esbuild to transpile the TS source code into an ESM source, NodeJs bundle, and a browser bundle
Uses the TypeScript compiler to generate the types.
Behavior
Before the change?
dist-node
,dist-types
,dist-web
... even though they are generated correctly.After the change?
Additional info
Pull request checklist
Does this introduce a breaking change?
Please see our docs on breaking changes to help!
Type: Breaking change
label)If
Yes
, what's the impact:Pull request type
Please add the corresponding label for change this PR introduces:
Type: Bug
Type: Maintenance