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

fix(build): switch to esbuild and tsc from pika #345

Merged
merged 14 commits into from
Jun 6, 2023
Merged

Conversation

kfcampbell
Copy link
Member

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?

  • Uses pika for the build system
  • The released npm package is missing most of the files generated by the build step. dist-node, dist-types, dist-web... even though they are generated correctly.

After the change?

  • Uses esbuild to generate the JS bundles
  • Uses the TypeScript compiler to generate the type definitions
  • The correct file matching patterns are used so we publish all the necessary files again.

Additional info

Pull request checklist

  • Tests for the changes have been added (for bug fixes / features)
  • Docs have been reviewed and added / updated if needed (for bug fixes / features)
  • Added the appropriate label for the given change

Does this introduce a breaking change?

Please see our docs on breaking changes to help!

  • Yes (Please add the Type: Breaking change label)
  • No

If Yes, what's the impact:

  • N/A

Pull request type

Please add the corresponding label for change this PR introduces:

  • Bugfix: Type: Bug
  • Dependencies/code cleanup: Type: Maintenance

@kfcampbell kfcampbell added the Type: Maintenance Any dependency, housekeeping, and clean up Issue or PR label Jun 5, 2023
Copy link
Contributor

@nickfloyd nickfloyd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

🎉

@wolfy1339
Copy link
Member

Don't forget to mark all type imports and exports

@gr2m
Copy link
Contributor

gr2m commented Jun 5, 2023

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?

@kfcampbell
Copy link
Member Author

@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 --verbatimModuleSyntax when compiling. Thoughts?

@gr2m
Copy link
Contributor

gr2m commented Jun 5, 2023

@gr2m we could probably use something like this eslint rule. Without taking an extra dependency, perhaps it'd be better to use --verbatimModuleSyntax when compiling. Thoughts?

yeah I would like to avoid adding eslint

--verbatimModuleSyntax looks great, I didn't know about this flag! It seems like the only gotcha about it is for modules with side effect, which we have been careful to avoid. I'd say let's add it to all the things

@wolfy1339
Copy link
Member

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.

@wolfy1339 wolfy1339 changed the title Switch to esbuild and tsc from pika fix(build): switch to esbuild and tsc from pika Jun 5, 2023
@kfcampbell
Copy link
Member Author

👍 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 tsc call in our npm run build command throws the following errors:

 sh$ npm run build

> @octokit/[email protected] build /home/kfcampbell/github/dev/auth-token.js
> node scripts/build.mjs && tsc -p tsconfig.json --verbatimModuleSyntax

src/hook.ts:2:3 - error TS1484: 'AnyResponse' is a type and must be imported using a type-only import when 'verbatimModuleSyntax' is enabled.

2   AnyResponse,
    ~~~~~~~~~~~

src/hook.ts:3:3 - error TS1484: 'EndpointDefaults' is a type and must be imported using a type-only import when 'verbatimModuleSyntax' is enabled.

3   EndpointDefaults,
    ~~~~~~~~~~~~~~~~

src/hook.ts:4:3 - error TS1484: 'EndpointOptions' is a type and must be imported using a type-only import when 'verbatimModuleSyntax' is enabled.

4   EndpointOptions,
    ~~~~~~~~~~~~~~~

src/hook.ts:5:3 - error TS1484: 'RequestInterface' is a type and must be imported using a type-only import when 'verbatimModuleSyntax' is enabled.

5   RequestInterface,
    ~~~~~~~~~~~~~~~~

src/hook.ts:6:3 - error TS1484: 'RequestParameters' is a type and must be imported using a type-only import when 'verbatimModuleSyntax' is enabled.

6   RequestParameters,
    ~~~~~~~~~~~~~~~~~

src/hook.ts:7:3 - error TS1484: 'Route' is a type and must be imported using a type-only import when 'verbatimModuleSyntax' is enabled.

7   Route,
    ~~~~~

src/hook.ts:8:3 - error TS1484: 'Token' is a type and must be imported using a type-only import when 'verbatimModuleSyntax' is enabled.

8   Token,
    ~~~~~


Found 7 errors in the same file, starting at: src/hook.ts:2

npm ERR! code ELIFECYCLE
npm ERR! errno 2
npm ERR! @octokit/[email protected] build: `node scripts/build.mjs && tsc -p tsconfig.json --verbatimModuleSyntax`
npm ERR! Exit status 2
npm ERR!
npm ERR! Failed at the @octokit/[email protected] build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/kfcampbell/.npm/_logs/2023-06-05T22_15_33_319Z-debug.log

@gr2m
Copy link
Contributor

gr2m commented Jun 5, 2023

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 @octokit/tsconfig

@wolfy1339
Copy link
Member

While we're at it, we should move the options that are common across the repos to @octokit/tsconfig

@wolfy1339
Copy link
Member

👍 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 tsc call in our npm run build command throws the following errors:

 sh$ npm run build

> @octokit/[email protected] build /home/kfcampbell/github/dev/auth-token.js
> node scripts/build.mjs && tsc -p tsconfig.json --verbatimModuleSyntax

src/hook.ts:2:3 - error TS1484: 'AnyResponse' is a type and must be imported using a type-only import when 'verbatimModuleSyntax' is enabled.

2   AnyResponse,
    ~~~~~~~~~~~

src/hook.ts:3:3 - error TS1484: 'EndpointDefaults' is a type and must be imported using a type-only import when 'verbatimModuleSyntax' is enabled.

3   EndpointDefaults,
    ~~~~~~~~~~~~~~~~

src/hook.ts:4:3 - error TS1484: 'EndpointOptions' is a type and must be imported using a type-only import when 'verbatimModuleSyntax' is enabled.

4   EndpointOptions,
    ~~~~~~~~~~~~~~~

src/hook.ts:5:3 - error TS1484: 'RequestInterface' is a type and must be imported using a type-only import when 'verbatimModuleSyntax' is enabled.

5   RequestInterface,
    ~~~~~~~~~~~~~~~~

src/hook.ts:6:3 - error TS1484: 'RequestParameters' is a type and must be imported using a type-only import when 'verbatimModuleSyntax' is enabled.

6   RequestParameters,
    ~~~~~~~~~~~~~~~~~

src/hook.ts:7:3 - error TS1484: 'Route' is a type and must be imported using a type-only import when 'verbatimModuleSyntax' is enabled.

7   Route,
    ~~~~~

src/hook.ts:8:3 - error TS1484: 'Token' is a type and must be imported using a type-only import when 'verbatimModuleSyntax' is enabled.

8   Token,
    ~~~~~


Found 7 errors in the same file, starting at: src/hook.ts:2

npm ERR! code ELIFECYCLE
npm ERR! errno 2
npm ERR! @octokit/[email protected] build: `node scripts/build.mjs && tsc -p tsconfig.json --verbatimModuleSyntax`
npm ERR! Exit status 2
npm ERR!
npm ERR! Failed at the @octokit/[email protected] build script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

npm ERR! A complete log of this run can be found in:
npm ERR!     /home/kfcampbell/.npm/_logs/2023-06-05T22_15_33_319Z-debug.log

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

package.json Outdated Show resolved Hide resolved
@kfcampbell
Copy link
Member Author

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 @octokit/tsconfig

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

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

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

@kfcampbell
Copy link
Member Author

kfcampbell commented Jun 6, 2023

While we're at it, we should move the options that are common across the repos to @octokit/tsconfig

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?

@kfcampbell
Copy link
Member Author

Note that as of 9a3587f, tests are failing in Node 16 with errors like:

    test/index.test.ts:1:10 - error TS1286: ESM syntax is not allowed in a CommonJS module when 'verbatimModuleSyntax' is enabled.

    1 import { request } from "@octokit/request";

I've resolved these instances by using the CommonJS syntax const { request } = require("@octokit/request");

However, we're also getting an issue in index.ts:

 FAIL  test/index.test.ts
  ● Test suite failed to run

    src/index.ts:11:1 - error TS1287: A top-level 'export' modifier cannot be used on value declarations in a CommonJS module when 'verbatimModuleSyntax' is enabled.

    11 export const createTokenAuth: StrategyInterface = function createTokenAuth(
       ~~~~~~

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?

@wolfy1339
Copy link
Member

I think we can add a tsconfig just for tests that disables that option

@kfcampbell
Copy link
Member Author

I'm picturing changing package.json to read something like:

...
  "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?

@wolfy1339
Copy link
Member

I'm picturing changing package.json to read something like:

...
  "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.
The only change that could be necessary is to the jest config to point it to the correct tsconfig

@kfcampbell
Copy link
Member Author

@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 verbatimModuleSyntax. Please take another look!

Copy link
Member

@wolfy1339 wolfy1339 left a 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 Show resolved Hide resolved
"sourceMap": true,
"verbatimModuleSyntax": false
},
"include": ["src/**/*"]
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
"include": ["src/**/*"]
"include": ["test/**/*"]

Copy link
Member

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.

Copy link
Member Author

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.

@kfcampbell
Copy link
Member Author

Would it be wise to move it into the test directory?

Good call! Done.

@kfcampbell
Copy link
Member Author

Once merged, any reservations to me rolling out the pattern introduced on this PR to the other octokit modules using pika?

@kfcampbell kfcampbell merged commit eaf16ab into main Jun 6, 2023
@kfcampbell kfcampbell deleted the switch-to-esbuild branch June 6, 2023 23:09
@github-actions
Copy link

github-actions bot commented Jun 6, 2023

🎉 This PR is included in version 3.0.4 🎉

The release is available on:

Your semantic-release bot 📦🚀

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
released Type: Maintenance Any dependency, housekeeping, and clean up Issue or PR
Projects
Archived in project
Development

Successfully merging this pull request may close these issues.

4 participants