Webpack dev server

[ry-randall]

As part of this PR:

1. Migrated everything to ES6 modules (helps w/ tree-shaking)
2. Cleaned up some of the imports
3. Created initial functioning webpack dev server & removed the old server.js
4. Added a couple scripts to package.json, including one for building the css

This PR is in response to: #805

[khanbot]

Hey @rrandallcainc,

Thanks for the PR! Mind signing our Contributor License Agreement?

When you've done so, go ahead and comment [clabot:check] and I'll check again.

Yours truly,
khanbot

[ry-randall]

[clabot:check]

[khanbot]

CLA signature looks good 👍

[edemaine]

@rrandallcainc Did you intentionally close this?

[ry-randall]

@edemaine Whoops, no. Not sure how that happened! Will take a look at the failing tests either tonight or tomorrow. It looks to be due to how Jest deals with es6 modules.

[kevinbarabash]

Right now the screenshot tests fail in screenshotter.js because server.js no longer exists. We'll need to figure out how to update screenshotter.js to work with webpack-dev-server.

[kevinbarabash]

Is setting modules: false to reduce overhead from the default "commons" setting?

[ry-randall]

Setting to modules: false enables the use of tree-shaking with webpack.

[kevinbarabash]

It's be nice to get away without renaming these files as people may be relying on the existing script name.

[ry-randall]

Agreed. Will look into it.

[kevinbarabash]

Would be it be possible to build this file when the server starts instead of checking it into source control?

[ry-randall]

Nice catch. Meant to take care of this prior to opening.

[ry-randall]

@kevinbarabash I brought back server.js, and it's now leveraging webpack-dev-server. It's still failing however. I'll look into this tomorrow.

[kevinbarabash]

@rrandallcainc one option might be to revert the changes to server.js and only use server.js with screenshotter.js for now and then we could figure out how to get webpack-dev-server working with the screenshot separately.

[ry-randall]

@kevinbarabash Agreed. Selenium tests are now back to running off of server.js.

[kevinbarabash]

@rrandallcainc I checked out your branch. I was having troubles loading 0.0.0.0:7936 in Safari 10.x. I think it may have something to do with webpack/webpack-dev-server#1090. I tried Safari 11.x and that solved the issue. I think it's probably okay to merge with this issue, but we'll want to call this out in the release notes.

I also tried running make build and ran into the following issue at the end:

~/KaTeX/node_modules/browserify/bin/cmd.js -t [ babelify ] katex.js --standalone katex > build/katex.js

~/KaTeX/katex.js:10
import ParseError from "./src/ParseError";
^
ParseError: 'import' and 'export' may appear only with 'sourceType: module'
make: *** [build/katex.js] Error 1

[kevinbarabash]

Sorry about some scripts being in package.json while others are in Makefile. We use make build as part of the release.sh script (it's called indirectly via make dist).

[ry-randall]

@kevinbarabash Build should now be working with the makefile. Perhaps now that we leverage webpack, it'll be worth leveraging for builds as well? Just a thought.

[ry-randall]

I reverted back to commonjs modules in babelrc. At this point there's no point in leveraging ES6 modules since it will need to be transpiled to commonjs for the consuming app.

Perhaps in the future, there could be two distributed builds (bundle.js & bundle.es6.js).

[kevinbarabash]

LGTM. Reloading is fast. The source maps work well in Chrome, but not in Safari (I blame Safari).

[kevinbarabash]

@rrandallcainc thanks for the PR. I think we'll want to use webpack eventually for the dist build. If we had two dist builds, would we need a second npm package?

[ry-randall]

@kevinbarabash I would agree with you that the source-maps issue is related to Safari/Webpack.

For separate builds, it's not 100% clear to me without further investigation. There's a thread here: webpack/webpack#1979 & a blog here: http://2ality.com/2017/04/transpiling-dependencies-babel.html which details the same problem.

TLDR; probably don't need to break it into separate npm packages. There are fields other than "main" that are intended for modules (pkg.module, pkg.es2015, pkg.esnext). Unfortunately, it's still not clear which one to leverage.

I'm happy to hear that things are building much faster now! There are a couple other things I'd like to work on, but I would be happy to help with more build related items in the future (if need be).

[caiofcm]

I am a beginner user of katex (as in web dev). I am not being able to import auto-render.js using the es6 module scheme.
It only works if I change the line in auto-render.js (https://github.com/Khan/KaTeX/blob/master/contrib/auto-render/auto-render.js)

-module.exports = renderMathInElement;
to
+export default renderMathInElement;
Analogously to what is done in #902

[kevinbarabash]

@caiofcm I was under the impression that you could use import statements when importing commonjs modules, but maybe that's only if you're using babel to smooth over the rough edges.

[ry-randall]

@caiofcm What are you using to build? Are you getting any errors on build time?

[caiofcm]

I am building with webpack (3.8.1) and .babelrc with "presets": [ "es2015"] }.

With the original code line module.exports = renderMathInElement I get the error:

Importing with:
var renderMathInElement = require('katex/contrib/auto-render/auto-render.js').renderMathInElement

Error: Uncaught TypeError: Cannot assign to read only property 'exports' of object '#<Object>'

Importing with (es6 style):
import renderMathInElement from 'katex/contrib/auto-render/auto-render.js'
error is as above and with the warning:
"export 'default' (imported as 'renderMathInElement') was not found in 'katex/contrib/auto-render/auto-render.js'

[ry-randall]

Yeah, this is a bug that exists with webpack. I remembered that this issue existed with webpack, but then forgot it when creating this PR.

Basically you can't mix es6 with commonjs in the same file. See: almende/vis#2934

We cannot change to ES6 format due to backwards compatibility. The solution would be to change the imports to commonjs format.

I've been extremely busy lately, but I can see if I can get this in maybe next week. Should be a simple fix. If you want, you can open a PR, and I can take a brief look.

Basically
import Blah from 'blah'; => const Blah = require('Blah').default;

[caiofcm]

@rrandallcainc thank you for your reply.
I wouldn't now how to properly create this PR.

But, if the other files in the project uses the export default syntax, such as parseTree.js and also from the contrib folder katex2tex.js, shouldn't auto-render.js also follow it ?