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

Move uglify invocation into npm scripts and remove grunt #628

Merged
merged 1 commit into from
Sep 25, 2016

Conversation

nornagon
Copy link
Contributor

Unfortunately the uglifyjs command line ends up being a little unwieldy, but that's a small price to pay for dropping grunt!

If the 'watch' functionality is useful to folks, I can add one of the options from https://www.keithcirkel.co.uk/how-to-use-npm-as-a-build-tool/#watch

Copy link
Member

@xPaw xPaw left a comment

Choose a reason for hiding this comment

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

🎉

@nornagon
Copy link
Contributor Author

Oh dear, windows' lack of globbing strikes again. I'll figure something out.

@nornagon
Copy link
Contributor Author

Some notes:

  • Windows doesn't support globbing (client/js/libs/*.js doesn't expand to the list of js files in windows shell)
  • Most nodejs libraries seem to solve this by adding a dependency on glob (which npm itself depends on), and parsing their cmd-line with it
  • UglifyJS is a unique snowflake and implements their own version of globbing, which will only glob-expand once per argument, so foo/*/*.js doesn't work.
  • Ultimately I think these libs/ should be either moved to dependencies installed via npm, included in the main bundle by import, or removed altogether.
  • Uglify can then be part of the webpack build process, and this npm script will go away.

So I think it's OK to explicitly list out the subdirectories for now.

@astorije astorije added Type: Feature Tickets that describe a desired feature or PRs that add them to the project. second review needed Meta: Do Not Merge This PR should not be merged. labels Sep 23, 2016
"build:font-awesome": "node scripts/build-fontawesome.js",
"build:grunt": "grunt",
"build:libs": "uglifyjs client/js/libs/*.js client/js/libs/jquery/*.js client/js/libs/handlebars/*.js -o client/js/libs.min.js --source-map client/js/libs.min.js.map --source-map-url libs.min.js.map -p relative",
Copy link
Member

Choose a reason for hiding this comment

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

I know you tried client/js/libs/*/*.js and that didn't work, but have you tried client/js/libs/**/*.js by any chance?

Copy link
Member

Choose a reason for hiding this comment

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

Alright, stupid question: do we want to uglify these? I don't think it matters too much in terms of performance.
EDIT: I also realize it makes things much simpler to load from the HTML file, so feel free to ignore if stupid comment :)

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 don't think there's a particularly good reason to uglify them other than for ease of loading, but webpack can fill this role once #609 lands and then we can drop uglify.

@@ -17,9 +17,9 @@
"scripts": {
"coverage": "istanbul cover node_modules/mocha/bin/_mocha -r test/fixtures/env.js test/**/*.js",
"start": "node index",
"build": "npm run build:font-awesome && npm run build:grunt && npm run build:handlebars",
"build": "npm-run-all build:*",
Copy link
Member

Choose a reason for hiding this comment

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

I am 99% sure we didn't use npm-run-all for a reason here. I think it was that we didn't want to use it too much, hoping to get rid of it sooner or later, but oh well. It's pretty cool that it supports *...

Copy link
Contributor Author

Choose a reason for hiding this comment

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

npm-run-all seems like a reasonable dependency at this point, but I can imagine simplifying things to a point where we can just use && (or & for parallel) and drop a dependency. It's simple enough for now though, I think.

@astorije
Copy link
Member

First of, amazing, I am so happy someone tackled this!

  • Windows doesn't support globbing (client/js/libs/*.js doesn't expand to the list of js files in windows shell)

Guess what, I think we added AppVeyor right after the last mess up there as well :D

  • Ultimately I think these libs/ should be either moved to dependencies installed via npm, included in the main bundle by import, or removed altogether.
  • Uglify can then be part of the webpack build process, and this npm script will go away.

Agreed.

So I think it's OK to explicitly list out the subdirectories for now.

Added a comment to try with **.
EDIT: Their simple_glob function, which really should be called simple_glob_placebo, doesn't seem to support ** either, sigh...
So yeah, having the libs in the repo was always a non-permanent solution, and we've made progress on that, so I'm happy with the current solution unless we have a better idea.

@nornagon
Copy link
Contributor Author

** doesn't even work on OSX, because npm scripts are executed with sh, not
bash, and sh doesn't support ** :(
On Thu, Sep 22, 2016 at 22:43 Jérémie Astori notifications@github.com
wrote:

First of, amazing, I am so happy someone tackled this!

  • Windows doesn't support globbing (client/js/libs/*.js doesn't expand
    to the list of js files in windows shell)

Guess what, I think we added AppVeyor right after the last mess up there
as well :D

  • Ultimately I think these libs/ should be either moved to
    dependencies installed via npm, included in the main bundle by import,
    or removed altogether.
  • Uglify can then be part of the webpack build process, and this npm
    script will go away.

Agreed.

So I think it's OK to explicitly list out the subdirectories for now.

Added a comment to try with *.
EDIT: Their simple_glob function, which really should be called
simple_glob_placebo, doesn't seem to support *
either, sigh...
So yeah, having the libs in the repo was always a non-permanent solution,
and we've made progress on that, so I'm happy with the current solution
unless we have a better idea.


You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#628 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAKjAExccFWyDnnV7aR9YfYTSeVfUzHuks5qs2bmgaJpZM4KEExb
.

Copy link
Member

@xPaw xPaw left a comment

Choose a reason for hiding this comment

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

Not cross-platform

@xPaw
Copy link
Member

xPaw commented Sep 24, 2016

Perhaps include uglifyjs in your webpack PR? Then the glob issues will be gone, and simplify it.

@nornagon
Copy link
Contributor Author

This is cross-platform (appveyor passed, as did the OSX + Linux travis builds). Folding it into the webpack PR is cleaner, though, I agree :)

@nornagon
Copy link
Contributor Author

I looked into folding this into #609, but ran into some problems. The libraries we include via the uglified libs.min.js are not CommonJS modules; they simply inject themselves into the global namespace. Webpack works by following require() calls, so it won't work with the libs unless we convert them all to use require/import.

IMHO this is still a win for now because we get to drop Grunt. As we further refactor the client we can shift stuff in libs/ over to CommonJS style and phase out uglify.

@astorije astorije removed Meta: Do Not Merge This PR should not be merged. second review needed labels Sep 25, 2016
@astorije astorije added this to the Next Release milestone Sep 25, 2016
@astorije
Copy link
Member

Not cross-platform

What's your issue with this, @xPaw? It seems like AppVeyor is happy and @nornagon kept cross-platformism in mind.

@xPaw
Copy link
Member

xPaw commented Sep 25, 2016

That's why:

ERROR: can't read file: client/js/libs/*.js

I get that by running npm build in powershell.

@xPaw
Copy link
Member

xPaw commented Sep 25, 2016

Figured it out, had to run npm install...

👍

@astorije astorije merged commit 38175b1 into thelounge:master Sep 25, 2016
@astorije
Copy link
Member

Awesome stuff, thanks @nornagon!

@astorije astorije modified the milestones: Next Release, 2.0.1 Sep 28, 2016
@astorije astorije removed this from the Next Release milestone Sep 28, 2016
matburnham pushed a commit to matburnham/lounge that referenced this pull request Sep 6, 2017
Move uglify invocation into npm scripts and remove grunt
@xPaw xPaw unassigned astorije and xPaw Mar 12, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Type: Feature Tickets that describe a desired feature or PRs that add them to the project.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

3 participants