-
Notifications
You must be signed in to change notification settings - Fork 1.2k
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
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.
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?
} | ||
|
||
if (IS_PRODUCTION) { | ||
baseConfig.plugins.push(terser()); |
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.
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
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.
CC @bterlson
const config: RollupOptions[] = [baseConfig as RollupOptions]; | ||
|
||
if (!IS_PRODUCTION) { | ||
config.push(makeBrowserTestConfig()); |
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'm not sure why this is gated on the production env var
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.
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.
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.
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\"", |
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.
can we confirm that we still get good callstacks on failed tests?
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.
also is the increase of timeout here necessary?
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.
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.
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.
@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", |
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.
what's actually using fs-extra? I didn't see it in the base rollup config except as an external
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.
good question. investigating why I did this.
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.
We are using it to create file streams for testing in Node.
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.
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\"", |
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.
also is the increase of timeout here necessary?
@@ -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", |
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.
nice!
sdk/template/template/package.json
Outdated
"typescript": "~3.9.3", | ||
"util": "^0.12.1" | ||
"util": "^0.12.1", | ||
"karma-typescript": "~5.0.3" |
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.
is this needed? we do not have it in TA.
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 is a leftover from when I was playing with this plugin in the karma config, thanks for pointing this out!
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.
Looks great! I left one minor comment.
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.
Changes look good! Thanks again for driving this. 👍
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
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
This PR is a first stab at creating a universal rollup configuration for our libraries. It migrates:
There are no warnings left on prod or testing builds, and there are some included changes to how tests are run:
shared-config
folder where shared configuration can live. This is a small shim program that loads a strongly-typed version of the config insrc/config/rollup.base.config.ts
.@azure/dev-tool/shared-config/rollup
.makeConfig
function, seerollup.config.js
below.chai
and use of eval insinon
andnise
) are automatically inhibited in the test configuration.Notes and next steps:
isNode
, and prefer instead to use browser mappings where appropriate, but since we're not shipping browser bundles.