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

feat!: adds support for ESM and Deno #295

Merged
merged 26 commits into from
Aug 4, 2020
Merged

feat!: adds support for ESM and Deno #295

merged 26 commits into from
Aug 4, 2020

Conversation

bcoe
Copy link
Member

@bcoe bcoe commented Jul 30, 2020

Using @mleguen and @QmarkC's work as a starting point, this refactor adds support for ESM and Deno.

The approach taken is as follows:

  1. TypeScript now targets es2015 module format.
  2. rollup is used to create a bundled CJS build of the library, including an index.cjs.d.ts (which is the binding that will be used for require statements).
  3. conditional exports are used to target both ESM and CJS.

Todo:

  • finish updating tests for tokenize-arg-string.ts.
  • document in README how to use deno and ESM.
  • investigate publishing to pika (I've added a module field, which I believe should allow us to start showing up on pika).
  • add config loading support to Deno.
  • make config loading work for ESM module.
  • make config loading throw reasonable error in browser.
  • get test coverage working for bundle.
  • configure release-please to push deno branch on release.

BREAKING CHANGE: decamelize and camelCase logic has been re-implemented, and may have some logical differences. Conditional exports for CJS vs., ESM may break some environments.

@bcoe bcoe requested review from QmarkC and mleguen July 30, 2020 05:07
@bcoe bcoe marked this pull request as ready for review July 30, 2020 07:21
// Cleanup the export statement in CJS typings file generated by rollup:
const legacyTypings = 'build/index.cjs.d.ts'
const contents = readFileSync(legacyTypings, 'utf8').replace(
'export { yargsParser as default };', 'export = yargsParser;'
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this a bug in rollup's support for --exports=default? If so, is there an open issue this could link to track when the workaround may become unnecessary?

Copy link
Member Author

Choose a reason for hiding this comment

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

@jkrems I wanted to keep the behavior of the CJS module identical to what it is today, with the main export being a callable function, i.e., not exports.default = yargsParser. However, for ESM/Deno I wanted to export default yargsParser... I wasn't sure how to indicate to rollup that I wanted the export = yargsParser behavior, while at the same time using the desired syntax in the source files themselves.

Maybe I should open a ticket on the tsc rollup plugin I'm using?

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, it seem like if the module.exports object is set to the default export, then export = defaultExport would be the correct typings to emit. At least from what I understand about TS type definitions. Not sure how that would affect future ESM consumers (that use vscode code completion) in the presence of named exports etc. but that's not necessarily a problem for today..?

Copy link
Contributor

@evocateur evocateur left a comment

Choose a reason for hiding this comment

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

Exciting!

scripts/replace-legacy-export.cjs Outdated Show resolved Hide resolved
package.json Outdated Show resolved Hide resolved
lib/yargs.ts Outdated Show resolved Hide resolved
rollup.config.js Show resolved Hide resolved
Co-authored-by: Daniel Stockman <5605+evocateur@users.noreply.github.com>
lib/yargs.ts Outdated Show resolved Hide resolved
bcoe and others added 2 commits July 31, 2020 21:34
Co-authored-by: Daniel Stockman <5605+evocateur@users.noreply.github.com>
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.

3 participants