-
-
Notifications
You must be signed in to change notification settings - Fork 247
Chore: add build step to bundle client-side assets #588
Conversation
["@babel/preset-env", { | ||
"modules": false, | ||
"targets": { | ||
"browsers": ["last 3 versions"] |
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 do we want to do for this? Relevant discussion: #543
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.
If we don't want to think about this yet, we can also specify forceAllTransforms: true
, and it will compile everything to be ES5-compatible.
root: true, | ||
extends: ["eslint"], | ||
parserOptions: { | ||
ecmaVersion: 2019 |
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'd ideally like to start using ES2015+ features, but I do think it's important we stick to features available in Espree so that we can dogfood it in our site. Does limiting ourselves to features available in Espree (so, features that have reached stage 4 and are supported by the parser) sound like a good policy?
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 think we should document this in the README (and maybe also create a CONTRIBUTING.md document)
@@ -15,6 +15,7 @@ exclude: | |||
- Gemfile.lock | |||
- package.json | |||
- node_modules | |||
- src |
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.
Since it's not ignoring assets/build, this ensures Jekyll waits to regenerate the site until after Webpack finishes and outputs the bundles (I don't think this really matters what order they run in, but this prevents Jekyll from regenerating the site when src
files are edited and then once more when the bundles are outputted).
_tools/fetch-sponsors.js
Outdated
@@ -13,7 +13,7 @@ | |||
//----------------------------------------------------------------------------- | |||
|
|||
const fs = require("fs"); | |||
const fetch = require("node-fetch"); | |||
const fetch = require("node-fetch"); // eslint-disable-line node/no-unpublished-require |
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 warning at the moment. Any ideas?
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.
node-fetch
is declared at devDependencies
, so the eslint-plugin-node
reported it.
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.
That makes sense!
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 know this isn't the rule's current behavior, but it seems like it shouldn't report when the root package.json has private: true
?
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.
@mysticatea Does that make sense? Maybe I'm missing something.
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 disable these rules in eslintrc? (since it is not a node lib.)
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.
If you have files: [...]
in your package.json, with publish files/dirs, that error should disappear.
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.
@aladdin-add’s suggestion makes sense to me. Will disable for the website.
}, | ||
output: { | ||
path: path.join(__dirname, "assets/build/js"), | ||
filename: "[name].js" |
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 need content hash here to avoid browsers cache issue?
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.
That's a good question. Going off this blog post by Netlify, it seems like we shouldn't need to. This seems to be the same conclusion the Babel team came to.
exclude: /node_modules|src\/js\/vendor/ | ||
}, | ||
{ | ||
test: /\.less$/, |
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.
Letting Webpack bundle these styles with their relevant JS bundles seems like an easier way to do this to me, now that the demo also requires the CodeMirror styles and less
doesn't support running over multiple files. The alternative is to set up some kind script that runs less
multiple times, but this felt like a cleaner solution to me. Thoughts?
exclude: | ||
- node_modules | ||
- src | ||
- vendor |
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 fixes the Travis CI build
9ec53aa
to
e5e3b08
Compare
Putting the do not merge label on this since the deploy preview version of the site isn't able to load all assets at the moment (I’m not seeing this locally so I’ll need to dig into it a bit to see what’s going on). |
@kaicataldo Could you possibly separate CodeMirror into it's own PR that we can merge before we do this one? I would like to see those changes before we do a big-bang build changes. |
@ilyavolodin I do generally try to decouple tasks like this, but the reason I switched out Orion for CodeMirror is because it was difficult to get Orion to play nicely with webpack and ES modules. I can spend time getting CodeMirror to work with the RequireJS setup we currently have (maybe by using a CDN?), but I’m not sure it buys us much if we’re going to be adding the bundling step soon anyway (unless you foresee us not merging this PR for a while). Edit: For reference, it's not a huge change, but the bulk of the changes are here (I bundle the CodeMirror CSS from |
As a follow up to deploy preview version not being able to load assets - it's because the URLs are using Edit: Fixed by #593 |
Apologies that this is a large PR - a lot of it is the removal of files and package-lock.json changes. I think I did a pretty good job of isolating individual tasks in commits, and I think reviewing commit by commit makes it a lot easier to review. |
As discussed via email, I'm going to go ahead and merge this. Happy to continue discussing any of these decisions! |
refs #576
I believe I have everything working except for the styling of the JS in the demo.I dug into this some more, and Orionorion/editor/built-editor.js
relies on RequireJS to requestorion/editor/stylers/application_javascript/syntax
, and it's currently not able to find the module.require
s the syntax highlighting file asynchronously at run time. I struggled with it for a bit and found it easier to just switch it out for CodeMirror (the Babel REPL uses this as well).There are a lot of ways we can organize the code, and after exploring a few options this felt like the solution with the least amount of developer friction and overhead. It gets rid of some top level directories (I'd ideally like to move a lot of these top level directories into sub-directories to clean up the root directory of the repo) and puts all the client-side assets in one
assets/
directory (which is what Jekyll suggests). I didn't renamestyles
tocss
, but we definitely can.Happy to discuss other ways of doing things, though, if others have strong opinions!
Landing this opens us up a lot of options to us, and I wanted to keep this (mostly) limited to implementing a build step in a sane way.
Finally, some things we definitely need to do if we land this as-is:
We'll also need to update the release script before the next release. That being said, I think it could be nice to explore instead bundling latest Espree/ESLint in this repository at build time in the future.
We'll need to change the command Netlify runs before this is merged so that it'll build correctly (note that this is why the deployment preview is broken - neither the styles nor the JS are being built right now).
Note: The design is slightly different for the demo, but I think it's a little cleaner looking:
See updated design below: