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

Update the packaging to split the bundles into esmodule and commonjs #55

Merged
merged 37 commits into from
May 25, 2023

Conversation

johnpmitsch
Copy link
Contributor

@johnpmitsch johnpmitsch commented May 20, 2023

The package uses this approach that bundles two different packages, one for esmodules and one for commonsjs, and then uses the exports value in package.json to determine which package to use.

Basically this will:

  1. build two bundles, the commonjs one in dist/packages/libs/sdk/cjs and the esmoudle one in dist/packages/libs/sdk/esm.
  2. copy over the package.json to dist/packages/libs/sdk/ with the exports section specifying the different imports
  3. Run a custom script to add a package.json to each bundle's directory with the correct "type" filled out

Each bundle uses the correct imports for the module system:

image

Here is the npm pack output:

image

Here's an example of using each package in a esm enviroment and a cjs environment, with the types being picked up by intellisense (and it all ran as expected)

image

image

@johnpmitsch johnpmitsch marked this pull request as draft May 20, 2023 16:32
@johnpmitsch johnpmitsch changed the title Urql WIP Update to use urql May 22, 2023
@johnpmitsch johnpmitsch changed the title Update to use urql Update the packaging to split the bundles into esmodule and commonjs packages May 23, 2023
@johnpmitsch johnpmitsch changed the title Update the packaging to split the bundles into esmodule and commonjs packages Update the packaging to split the bundles into esmodule and commonjs May 23, 2023
@johnpmitsch johnpmitsch marked this pull request as ready for review May 24, 2023 17:38
@@ -1 +1 @@
QUICKNODE_GQL_API_KEY=replaceme
QUICKNODE_GRAPH_API_KEY=replaceme
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Just updated the name here and in the docs and code for consistency

Copy link
Contributor Author

@johnpmitsch johnpmitsch May 24, 2023

Choose a reason for hiding this comment

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

I had to update this to yaml file since we are now using type: "module" which doesn't play nice with codegen - see issue here

"main": "./src/index.js",
"module": "./src/index.esm.js",
"types": "./src/index.d.ts",
"type": "module",
Copy link
Contributor Author

Choose a reason for hiding this comment

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

I updated this because I'm trying to optimize for esmodules, so figured it would be helpful if this is the default locally. I don't think it matters which we use locally because of the individual exports below and the script to add a package.json for each bundle's subdirectory (tools/scripts/sdk_package_json.mjs)

".": {
"import": "./esm/index.js",
"require": "./cjs/index.js"
}
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Here is the part that dynamically will import the correct bundle based on whether the package is imported with require or import

@@ -159,7 +159,7 @@ export class NftsController {
private async getByWalletAddress(
variables: WalletNFTsByAddressQueryVariablesType & NonQueryInput
): Promise<WalletNFTsByAddressFormattedResult> {
const { chain, contractAddresses, ...queryVariables } = variables;
const { chain, ...queryVariables } = variables;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This was a small change that I missed from 42a6627, I noticed in the intellisense options when testing out the built package

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Lots of lines removed because I no longer format this by default, which ended up saving a lot of space on the bundle (I think it was around 30kb)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

With the other codegen changes this got formatted slightly differently, not sure exactly why. In the rollup config we are specifying json({ compact: true }) so it's fine to be formatted here.

CodegenEthMainnetWalletNFTsByAddressQueryVariables & {
contractAddresses?: string[];
};
CodegenEthMainnetWalletNFTsByAddressQueryVariables;
Copy link
Contributor Author

Choose a reason for hiding this comment

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

This was a small change that I missed from 42a6627, I noticed in the intellisense options when testing out the built package, it's not a valid option.

@@ -8,7 +8,6 @@
"noImplicitReturns": true,
"noFallthroughCasesInSwitch": true,
"esModuleInterop": true,
"declaration": true,
Copy link
Contributor Author

Choose a reason for hiding this comment

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

we generate these with the rollup dts plugin

"types": ["node"],
"declaration": true
"target": "ES2020",
"module": "ES2020",
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It's not ideal but I had to add this back, it was removed in #56 because I thought we no longer needed it.

I'm seeing this error, if I re-record the failing tests it will show up on other previously passing tests. This was similar to the apollo errors I saw that required this, IIRC it basically came down to race conditions because of the speed at the tests are executed. Can look into it more when I get a chance

image

Copy link
Contributor Author

@johnpmitsch johnpmitsch May 25, 2023

Choose a reason for hiding this comment

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

Getting the actual error, it's the same as the one I ran into with Apollo, I have to dig into it a bit more of the why here, it could have something to do with the http request mocking

      CombinedError: [Network] req.setHeader is not a function
          at operation (/Users/johnmitsch/qn-oss/packages/libs/sdk/node_modules/@urql/core/src/utils/result.ts:168:1)
          at networkMode (/Users/johnmitsch/qn-oss/packages/libs/sdk/node_modules/@urql/core/src/internal/fetchSource.ts:151:1)
          at processTicksAndRejections (node:internal/process/task_queues:96:5)
          at /Users/johnmitsch/qn-oss/packages/libs/sdk/node_modules/wonka/dist/wonka.js:342:20

@johnpmitsch johnpmitsch merged commit 10673af into main May 25, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants