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

[dev-tool] Shared rollup config factory #10923

Merged
merged 20 commits into from
Sep 28, 2020

Conversation

willmtemple
Copy link
Contributor

This PR is a first stab at creating a universal rollup configuration for our libraries. It migrates:

  • template
  • ai-form-recognizer
  • ai-text-analytics

There are no warnings left on prod or testing builds, and there are some included changes to how tests are run:

  • dev-tool now holds a shared-config folder where shared configuration can live. This is a small shim program that loads a strongly-typed version of the config in src/config/rollup.base.config.ts.
    • Load the shim by requiring @azure/dev-tool/shared-config/rollup.
    • Pass the package JSON object to the makeConfig function, see rollup.config.js below.
  • There is now only one configuration that builds both the release rollup as well as the browser test build.
  • Node tests are now run using ts-node, and are no longer bundled.
  • All node builtins, package dependencies, and dev dependencies are now excluded from the rollup bundle by default (no more messing with "excludes". In browser test mode, everything is bundled together.
  • Node globals and builtins are automatically shimmed in the browser as appropriate.
  • Known inconsequential warnings (such as circular dependency in chai and use of eval in sinon and nise) are automatically inhibited in the test configuration.
  • The build generates source maps (as it always has), and karma is set up to load them. Node test runs get source map support automatically through ts-node.

Notes and next steps:

  • Most libraries should remove instances of isNode, and prefer instead to use browser mappings where appropriate, but since we're not shipping browser bundles.
  • If this approach is agreeable, I'll start looking at Azure core.

@willmtemple willmtemple added Client This issue points to a problem in the data-plane of the library. dev-tool Issues related to the Azure SDK for JS dev-tool labels Aug 29, 2020
Copy link
Member

@xirzec xirzec left a comment

Choose a reason for hiding this comment

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

Overall, I love the direction of this PR as not having to copy-paste confusing/massive configuration files is a breath of fresh air.

I left some minor comments, the oddest being the existence of files with strange names that I think got committed as part of some buffer?

common/tools/dev-tool/' Outdated Show resolved Hide resolved
}

if (IS_PRODUCTION) {
baseConfig.plugins.push(terser());
Copy link
Member

Choose a reason for hiding this comment

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

do we actually use/need this? Since we don't ship browser bundles I'm not sure why we'd want to bother minifying them

Copy link
Contributor Author

Choose a reason for hiding this comment

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

const config: RollupOptions[] = [baseConfig as RollupOptions];

if (!IS_PRODUCTION) {
config.push(makeBrowserTestConfig());
Copy link
Member

Choose a reason for hiding this comment

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

I'm not sure why this is gated on the production env var

Copy link
Contributor Author

Choose a reason for hiding this comment

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

to me the logic was about whether or not we were building a production-ready distribution bundle, and in that case it seemed like we wouldn't need to generate the browser testing bundle, but honestly I don't know if/where we use NODE_ENV=production in the pipelines. I was expecting that I would see a CI failure if the browser test bundle was needed in any production contexts, but since I didn't...

I'll need to investigate this a little further.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Thought about it and I have come around to the same point of view on both this and the other IS_PRODUCTION comment. We don't need to do any minifying and we can just build the browser bundle by default. In any case, the NODE_ENV is the wrong switch to use here. I will instead add an options parameter with an opt-out flag for those packages that want to disable the browser test build.

@@ -70,7 +70,7 @@
"test:node": "npm run build:test && npm run unit-test:node && npm run integration-test:node",
"test": "npm run build:test && npm run unit-test && npm run integration-test",
"unit-test:browser": "karma start --single-run",
"unit-test:node": "mocha --require source-map-support/register --reporter ../../../common/tools/mocha-multi-reporter.js --timeout 120000 --full-trace dist-test/index.node.js",
"unit-test:node": "mocha -r esm --require ts-node/register --reporter ../../../common/tools/mocha-multi-reporter.js --timeout 1200000 --full-trace \"test/{,!(browser)/**/}*.spec.ts\"",
Copy link
Member

Choose a reason for hiding this comment

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

can we confirm that we still get good callstacks on failed tests?

Copy link
Member

Choose a reason for hiding this comment

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

also is the increase of timeout here necessary?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

timeout shouldn't have been changed, that must be a bug. Error traces in console for both node and browser at least looked good but I'll try with vscode debugging to make sure that works as well.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@deyaaeldeen actually, Form Recognizer was the only one with the lower timeout.

@@ -112,6 +108,7 @@
"eslint-plugin-no-null": "^1.0.2",
"eslint-plugin-no-only-tests": "^2.3.0",
"eslint-plugin-promise": "^4.1.1",
"fs-extra": "^8.1.0",
Copy link
Member

Choose a reason for hiding this comment

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

what's actually using fs-extra? I didn't see it in the base rollup config except as an external

Copy link
Contributor Author

Choose a reason for hiding this comment

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

good question. investigating why I did this.

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 are using it to create file streams for testing in Node.

sdk/template/template/package.json Outdated Show resolved Hide resolved
sdk/textanalytics/ai-text-analytics/] Outdated Show resolved Hide resolved
Copy link
Member

@deyaaeldeen deyaaeldeen left a comment

Choose a reason for hiding this comment

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

Awesome! Thanks for doing this. Looks great except for the weird files checked in. IIRC, last time I used vscode debugger with ts-node, it worked well. Can you verify it works in this PR?

@@ -70,7 +70,7 @@
"test:node": "npm run build:test && npm run unit-test:node && npm run integration-test:node",
"test": "npm run build:test && npm run unit-test && npm run integration-test",
"unit-test:browser": "karma start --single-run",
"unit-test:node": "mocha --require source-map-support/register --reporter ../../../common/tools/mocha-multi-reporter.js --timeout 120000 --full-trace dist-test/index.node.js",
"unit-test:node": "mocha -r esm --require ts-node/register --reporter ../../../common/tools/mocha-multi-reporter.js --timeout 1200000 --full-trace \"test/{,!(browser)/**/}*.spec.ts\"",
Copy link
Member

Choose a reason for hiding this comment

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

also is the increase of timeout here necessary?

@willmtemple willmtemple requested a review from a team as a code owner September 12, 2020 03:32
@@ -108,7 +107,6 @@
"eslint-plugin-no-null": "^1.0.2",
"eslint-plugin-no-only-tests": "^2.3.0",
"eslint-plugin-promise": "^4.1.1",
"fs-extra": "^8.1.0",
Copy link
Member

Choose a reason for hiding this comment

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

nice!

"typescript": "~3.9.3",
"util": "^0.12.1"
"util": "^0.12.1",
"karma-typescript": "~5.0.3"
Copy link
Member

Choose a reason for hiding this comment

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

is this needed? we do not have it in TA.

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 is a leftover from when I was playing with this plugin in the karma config, thanks for pointing this out!

Copy link
Member

@deyaaeldeen deyaaeldeen left a comment

Choose a reason for hiding this comment

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

Looks great! I left one minor comment.

Copy link
Member

@xirzec xirzec left a comment

Choose a reason for hiding this comment

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

Changes look good! Thanks again for driving this. 👍

@willmtemple willmtemple merged commit 8bb505f into Azure:master Sep 28, 2020
openapi-sdkautomation bot pushed a commit to AzureSDKAutomation/azure-sdk-for-js that referenced this pull request Dec 1, 2020
Add some profile tag for go SDK to serve the new profile 2020-09-01 (Azure#10923)

* some update of the tags for profiles

* final update for profiles

* a fix of tag name

* Remove the changes for web readme since it does not work

* Rename tag for compute, revert keyvault tag change

* update
openapi-sdkautomation bot pushed a commit to AzureSDKAutomation/azure-sdk-for-js that referenced this pull request Dec 1, 2020
Add some profile tag for go SDK to serve the new profile 2020-09-01 (Azure#10923)

* some update of the tags for profiles

* final update for profiles

* a fix of tag name

* Remove the changes for web readme since it does not work

* Rename tag for compute, revert keyvault tag change

* update
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Client This issue points to a problem in the data-plane of the library. dev-tool Issues related to the Azure SDK for JS dev-tool
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants