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

Manage frontend dependencies with npm/yarn and webpack #1072

Merged
merged 5 commits into from
Mar 28, 2018

Conversation

ArthurHoaro
Copy link
Member

@ArthurHoaro ArthurHoaro commented Jan 31, 2018

Relates to #755

  • move default theme assets to /assets/default
  • asset folders in default template are now git ignored
  • handle assets dependencies with yarn (and fixed version with yarn.lock)
  • handle assets compilation with webpack 2

JS:

  • use ES6 syntax
  • compile it with babel
  • minify it using babel-minify-webpack-plugin
  • initiate splitting JS files into separate modules (base/picwall/[todo])
  • dependencies are now bundled with Shaarli's JS file (awesomplete and blazy)
  • Use JS linting

CSS:

  • move Shaarli's pure CSS to SASS
  • dependencies are now bundled with Shaarli's CSS file (awesomplete/purecss/fontawesome)
  • CSS is now minified

Images:

  • compressed at compilation by image-webpack-loader

Usage with npm and yarn installed:

yarn install
yarn run build

TODO in this PR:

  • Documentation
  • Migrate vintage theme
  • Makefile targets and Travis build
  • Docker images (do it in another PR)
  • ESLint

TODO list for later:

  • JSLint: fix 1k JS style errors and add it to Travis build
  • CSSLint: fix CSS style erroors and add it to Travis build
  • Split JS code into dedicated module files
  • JS unit tests
  • Use SASS features such as variables for colors
  • ???
  • Profit!

@ArthurHoaro ArthurHoaro added enhancement in progress documentation tools developer tools template HTML rendering 3rd party interoperability with third-party platforms javascript client-side rendering labels Jan 31, 2018
@ArthurHoaro ArthurHoaro added this to the 0.10.0 milestone Jan 31, 2018
@ArthurHoaro ArthurHoaro self-assigned this Jan 31, 2018
@ArthurHoaro
Copy link
Member Author

I don't think I can build the armhf architecture Docker image.

@@ -1,4 +1,4 @@
FROM alpine:3.6
FROM mhart/alpine-node:9
Copy link
Member

Choose a reason for hiding this comment

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

at this point, it would be worth migrating to a Docker multi-stage build to avoid providing an image embedding development resources (Composer and NodeJS) that are not needed to run the application

I can work on this in a separate issue/PR, as there's a bit of Docker involved in the next release with #1010

Copy link
Member Author

Choose a reason for hiding this comment

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

Oh! I've never heard of multi-stage build, it looks great! I'll try to play with it in another PR.

Copy link
Member

Choose a reason for hiding this comment

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

I've started to work on this to use the composer image to download the Shaarli archive and resolve PHP deps :)


const extractCssVintage = new ExtractTextPlugin({
filename: "../css/[name].css",
publicPath: 'tpl/default/css/',
Copy link
Member

Choose a reason for hiding this comment

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

s/default/vintage/

{
entry: {
shaarli: './assets/vintage/js/base.js',
picwall: './assets/default/js/picwall.js',
Copy link
Member

Choose a reason for hiding this comment

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

s/default/vintage/ (not sure about this one... are resources from default needed by vintage?)

Copy link
Member Author

Choose a reason for hiding this comment

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

They are. But maybe I should add a common folder instead?

Copy link
Member

Choose a reason for hiding this comment

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

yes, I think it would make things clearer and help isolating template-specific resources

import Awesomplete from 'awesomplete';

// CSS
import '../scss/shaarli.scss';
Copy link
Member

Choose a reason for hiding this comment

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

referring to SASS / assets from JS code should not be necessary; asset copy and generation should be handled by Webpack

@virtualtam
Copy link
Member

Nice!

This is a great step towards more flexible front-end generation and asset management :)

The diff is quite huge though, maybe we could start with commits dealing with the low hanging fruits? E.g.:

  • JS cleanup: var, let, const
  • asset location update

@ArthurHoaro
Copy link
Member Author

Thanks for the early review. I only had experience with webpack on POCs and such. I'll probably try to redo everything step by step to get a clean commit log. The global diff will probably be huge anyway. Note that yarn.lock takes 4.6k line of the +5k lines here.

I'll also use real ES6 syntax here and run eslint on travis in this PR.

@virtualtam
Copy link
Member

Yep, Webpack has an awful lot of dependencies. Do we actually need it for our use case?

It seems very powerful to create full-fledged frontend application bundles (as in Angular/React/Vue + Node + SASS/SCSS), but quite overkill to package a handful of dependencies.

For similar use cases (backend serving static pages with 3rd-party CSS/JS), I went back to using:

  • npm/yarn to resolve dependencies
  • npm tasks to copy bundled dependencies from node_modules to the app's asset directories
  • Gulp tasks to render SCSS/SASS to CSS and minify assets

Ping @nicolasdanelon and @tcitworld who contributed to the discussion in #755 :)

@tcitworld
Copy link

Yep, Webpack has an awful lot of dependencies. Do we actually need it for our use case?

These are devDependencies, not the project dependencies.

@virtualtam
Copy link
Member

Our needs here are quite basic:

  • resolve frontend dependencies
  • compile SASS to CSS
  • compile ES6 modules to plain JS
  • minify and bundle assets

Dependencies (and overhead) are worth keeping to a minimum, so we can easily maintain our build toolchain while avoiding headaches 🤕

@ArthurHoaro
Copy link
Member Author

Well, who can do more can do less. I'm sure we can do everything using other tools packaged in a single Makefile target, but once configured webpack does everything easily and has a lot of resources since it has more or less became a standard.

Regarding our build toolchain and dev tools, I would tend to say that the ease of use overcomes their weight.

@ArthurHoaro ArthurHoaro changed the title WIP: Manage frontend dependencies with npm/yarn and webpack Manage frontend dependencies with npm/yarn and webpack Feb 24, 2018
@ArthurHoaro
Copy link
Member Author

Ok I think I'm mostly done here. I've entirely rewritten the commit log to make everything more understandable, even though the JS rewrite diff isn't really readable.

Also I was pleasantly surprise to see that yarn is already installed by default in Travis PHP image.

@ArthurHoaro ArthurHoaro force-pushed the feature/modern-front-end branch 2 times, most recently from 7dcf0b5 to 5c7caf4 Compare February 26, 2018 20:23
"rules": {
"no-param-reassign": 0, // manipulate DOM style properties
"no-restricted-globals": 0, // currently Shaarli uses alert/confirm, could be be improved later
"no-alert": 0, // currently Shaarli uses alert/confirm, could be be improved later
Copy link
Member

Choose a reason for hiding this comment

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

time to raise some issues then :)

I'm about to do the same for the TODOs concerning usage of die() and exit() in PHP code

Copy link
Member Author

Choose a reason for hiding this comment

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

Issue raised in #1095

before_script:
- PATH=${PATH//:\.\/node_modules\/\.bin/}
script:
- make clean
- make check_permissions
- make eslint
Copy link
Member

Choose a reason for hiding this comment

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

frontend lint & tests should be run in a dedicated JS / Node matrix to avoid cluttering the PHP test environments

this will be a bit tricky so it's OK to address this point in a separate PR

Copy link
Member

@virtualtam virtualtam left a comment

Choose a reason for hiding this comment

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

Tested on my local development environment, works fine :)

@ArthurHoaro do you want to wait until a PR addressing Docker builds is submitted before merging?

@ArthurHoaro
Copy link
Member Author

I think that we should wait, otherwise the master image will be broken.

"font-awesome": "^4.7.0",
"pure-extras": "^1.0.0",
"purecss": "^1.0.0"
},
Copy link
Member

Choose a reason for hiding this comment

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

Should we setup some automation to warn us about new upstream releases of the dependencies? (or can yarndo that for us?)

Great patch! It adds requirements for yarn+node sources.lists + packages in the build environment, but I can live with that :) Looks definitely more manageable.

Copy link
Member

Choose a reason for hiding this comment

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

@ArthurHoaro ArthurHoaro merged commit c81f1af into shaarli:master Mar 28, 2018
virtualtam added a commit to virtualtam/Shaarli that referenced this pull request Apr 4, 2018
Relates to shaarli#1072

Changed:
- update paths to resource files (assets, images)

Removed:
- references to resources now resolved through NPM
- licenses corresponding to the aforementioned resources

Signed-off-by: VirtualTam <[email protected]>
virtualtam added a commit to virtualtam/Shaarli that referenced this pull request Apr 4, 2018
Relates to shaarli#1072

Changed:
- update paths to resource files (assets, images)

Removed:
- references to resources now resolved through NPM
- licenses corresponding to the aforementioned resources

Signed-off-by: VirtualTam <[email protected]>
virtualtam added a commit to virtualtam/Shaarli that referenced this pull request Apr 4, 2018
Relates to shaarli#1072

Changed:
- update paths to resource files (assets, images)

Removed:
- references to resources now resolved through NPM
- licenses corresponding to the aforementioned resources

Signed-off-by: VirtualTam <[email protected]>
virtualtam added a commit to virtualtam/Shaarli that referenced this pull request Apr 4, 2018
Relates to shaarli#1072

Changed:
- update paths to resource files (assets, images)

Removed:
- references to resources now resolved through NPM
- licenses corresponding to the aforementioned resources

Signed-off-by: VirtualTam <[email protected]>
virtualtam added a commit to virtualtam/Shaarli that referenced this pull request Apr 5, 2018
Relates to shaarli#1072

Changed:
- update paths to resource files (assets, images)

Removed:
- references to resources now resolved through NPM
- licenses corresponding to the aforementioned resources

Signed-off-by: VirtualTam <[email protected]>
virtualtam added a commit to virtualtam/Shaarli that referenced this pull request Apr 5, 2018
Relates to shaarli#1072

Changed:
- update paths to resource files (assets, images)

Removed:
- references to resources now resolved through NPM
- licenses corresponding to the aforementioned resources

Signed-off-by: VirtualTam <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
3rd party interoperability with third-party platforms documentation enhancement in review javascript client-side rendering template HTML rendering tools developer tools
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants