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

📦 Switch to Yarn workspaces; overhaul build system #1741

Merged
merged 26 commits into from
Nov 16, 2017
Merged

Conversation

adidahiya
Copy link
Contributor

@adidahiya adidahiya commented Oct 19, 2017

Fixes #1031.
Fixes #116.
Fixes #436.
Fixes #1527.
Fixes #780.

See #1786 for more details about the build system overhaul.

Changes proposed in this pull request:

  • Upgrade dev setup to Node 8.5 and Yarn 1.0
    • I did not upgrade engines in package.json because this all probably still works in Node 6... (no it's not worth testing for it in CI, if we get bug report we can just bump engines to the range we care about)
  • Switch to using Yarn workspaces
    • This makes installs faster, forces us to be more consistent about sharing the same dependencies across packages, and makes lockfile resolution easier.
  • Bump various dev dependencies within existing semver ranges
  • Bump documentalist
  • Bump chai
  • Bump stylelint-scss
  • Bump ts-loader
  • Bump webpack from v1 to v3!!

@adidahiya
Copy link
Contributor Author

adidahiya commented Oct 19, 2017

I think our version of webpack doesn't like resolving node_modules at the root... or we might have to explicitly add ../../node_modules to the list of bundler resolution paths.

Copy link
Contributor

@giladgray giladgray left a comment

Choose a reason for hiding this comment

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

love where this is going! mostly got some questions about reasoning behind some of these changes

package.json Outdated
"tslint-react": "^3.2.0",
"typescript": "~2.2.1",
"typescript": "~2.4.2",
Copy link
Contributor

Choose a reason for hiding this comment

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

😱 hooray! is this a safe change for .d.ts compatibility?

Copy link
Contributor Author

@adidahiya adidahiya Oct 20, 2017

Choose a reason for hiding this comment

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

Should be safe since we're not using new features, but there are no guarantees. I would just highlight the small chance of breaking syntax in the release notes and if something does come up, file it as a low priority issue to fix in the future. I don't want to wait until the next major version to upgrade typescript.

this.timeoutIds.push(handle);
return () => clearTimeout(handle);
return () => window.clearTimeout(handle);
Copy link
Contributor

Choose a reason for hiding this comment

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

curious: why add the window reference?

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 dependency hoisting, we get @types/node at the root. the global setTimeout resolves to node's setTimeout before it sees window.setTimeout in lib.d.ts. so we make this more explicit

Copy link
Contributor

Choose a reason for hiding this comment

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

would be cool to add a code comment to that effect

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 pretty obvious when you make the mistake. it's a compile error. the typedef takes you to a different file. not going to add a comment

Copy link
Contributor

@giladgray giladgray Oct 24, 2017

Choose a reason for hiding this comment

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

what do you think about tslint banning non-window references to set/clearTimeout/Interval? particularly clearTimeout, which does not produce a compiler error.

@@ -29,13 +29,6 @@ describe("<Callout>", () => {
assert.isTrue(wrapper.hasClass(Classes.INTENT_DANGER));
});

it("spreads HTML props", () => {
Copy link
Contributor

Choose a reason for hiding this comment

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

why remove this test?

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 didn't find it very useful, and it was using invalid HTML props

@@ -14,7 +14,7 @@ const Heading: React.SFC<IHeadingTag> = ({ level, route, value }) =>
React.createElement(
`h${level}`,
{ className: "docs-title" },
<a className="docs-anchor" key="anchor" name={route} />,
Copy link
Contributor

Choose a reason for hiding this comment

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

wait I think this attribute is critical to functionality! there's a selector that checks the name attr (although something is currently broken #1682)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

name is not a valid HTML anchor attribute according to the latest lib.d.ts

Copy link
Contributor

Choose a reason for hiding this comment

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

data-name then please

@@ -1,5 +1,5 @@
{
"name": "blueprintjs.com/docs",
"name": "@blueprintjs/site-docs",
Copy link
Contributor

Choose a reason for hiding this comment

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

idea behind the previous name was that it's obvious that the package is not published. I'm sure you ran into the issue where / is an invalid char in yarn package names. how about blueprintjs.com-docs?

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 find it weird that this monorepo doesn't follow the standard of using a single NPM scope. "private": true should make that publishing fact obvious enough.


// borrowed from https://github.com/TypeStrong/ts-loader

declare var require: {
Copy link
Contributor

Choose a reason for hiding this comment

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

awesome that we can delete this! where does the type info come from now?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@types/node at the root

"@types/react": "^16.0.14",
"@types/react-addons-css-transition-group": "^15.0.3",
"@types/react-addons-transition-group": "^15.0.1",
"@types/react-dom": "^16.0.1",
Copy link
Contributor

Choose a reason for hiding this comment

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

🎆 awesome sauce! although might it be more accurate to use the latest 15.x types instead?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The types are basically the same and it's much easier to upgrade everything to latest; we won't be able to use new features at runtime anyway since we run react 15 in development.

Copy link
Contributor

Choose a reason for hiding this comment

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

definitely buy the upgrade/similarity arguments, but my concern with this change is that new features are available at compile time but not at run time.

if you're not concerned then I'm chill.

@giladgray
Copy link
Contributor

@adidahiya I think the build stuff is now in a good state here! Tasks are working and development is possible. Now, all that remains should be some test fixes to get a passing build!

@cmslewis would you mind contributing fixes for the table tests?

@adidahiya
Copy link
Contributor Author

recent changes lgtm

@blueprint-bot
Copy link

Comment out broken tests :/

Preview: documentation | landing | table
Coverage: core | datetime

Copy link
Contributor

@giladgray giladgray left a comment

Choose a reason for hiding this comment

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

is it safe for me to approve this?

@giladgray giladgray changed the title [WIP] Switch to Yarn workspaces; upgrade some dev dependencies Switch to Yarn workspaces; upgrade some dev dependencies Oct 27, 2017
@giladgray giladgray changed the title Switch to Yarn workspaces; upgrade some dev dependencies 📦 Switch to Yarn workspaces; upgrade some dev dependencies Oct 27, 2017
Copy link
Contributor

@giladgray giladgray left a comment

Choose a reason for hiding this comment

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

not safe, as docs site does not load (table and landing are good though)

# Conflicts:
#	packages/site-docs/src/require-shim.d.ts
#	packages/site-landing/src/require-shim.d.ts
#	packages/table/preview/require-shim.d.ts
@blueprint-bot
Copy link

Merge remote-tracking branch 'origin/master' into ad/workspaces

Preview: documentation | landing | table
Coverage: core | datetime

@blueprint-bot
Copy link

Merge remote-tracking branch 'origin/master' into ad/workspaces

Preview: documentation | landing | table
Coverage: core | datetime

@adidahiya adidahiya changed the title 📦 Switch to Yarn workspaces; upgrade some dev dependencies 📦 Switch to Yarn workspaces; overhaul build system Nov 16, 2017
@blueprint-bot
Copy link

Remove Gulpfile.js

Preview: documentation | landing | table
Coverage: core | datetime

@adidahiya
Copy link
Contributor Author

ready to go

Copy link
Contributor

@cmslewis cmslewis left a comment

Choose a reason for hiding this comment

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

🔥

@adidahiya adidahiya dismissed giladgray’s stale review November 16, 2017 19:51

preview sites look fine now

Copy link
Contributor

@giladgray giladgray left a comment

Choose a reason for hiding this comment

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

🚢 🚢 🚢 🚢 🚢 🚢 🚢 🚢 🚢

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants