Skip to content
This repository has been archived by the owner on Oct 24, 2021. It is now read-only.

CSS preprocessors, JavaScript compilers, and the Meteor Build Tool #41

Closed
tmeasday opened this issue Oct 19, 2015 · 27 comments
Closed

CSS preprocessors, JavaScript compilers, and the Meteor Build Tool #41

tmeasday opened this issue Oct 19, 2015 · 27 comments
Assignees
Labels

Comments

@tmeasday
Copy link
Contributor

Article outline

https://github.com/meteor/guide/blob/master/outlines/build-tool.md

Major decision points

  1. Use ES2015+ everywhere via the ecmascript package, if you really want to you can use coffeescript instead but all of our code samples will be against ES2015.
  2. Use autoprefixer by using one of the community minifier packages that have it built-in, rather than by building it into the CSS compiler. In the future, we will need a separate build step for CSS post-processing.
  3. Ideally the Meteor 1.3 build tool will support NPM on the client and server natively, but until then meteorhacks:npm and cosmos:browserify are the best options
@stubailo stubailo changed the title The Build Tool CSS preprocessors, JavaScript transpilation, and the Meteor Build Tool Oct 19, 2015
@stubailo
Copy link
Contributor

The initial outline:

Meteor guide: The build tool

Meteor brings sane, zero-configuration defaults to the previously tedious tasks of compiling, concatenating, minifying, and transforming assets.

  1. How to use popular transpiled languages in Meteor out of the box:
    1. ES2015+
    2. LESS
    3. SASS
    4. Coffee
    5. TypeScript
  2. How to use packages from other packaging systems:
    1. Compatibility directory and 'bare' files
    2. Bower
    3. NPM

We should also link to the section about making your own build plugin.

@stubailo stubailo changed the title CSS preprocessors, JavaScript transpilation, and the Meteor Build Tool CSS preprocessors, JavaScript compilers, and the Meteor Build Tool Oct 19, 2015
@vladshcherbin
Copy link

A section about how to use css Autoprefixer after compiling scss/less/etc will be great.

@stubailo
Copy link
Contributor

Let's look at some key decisions that need to be made:

Easy parts

  • ES2015 is built-in now, we just have to explain what it is and what features we support
  • LESS has a "core" package for it, just need to explain cross-package imports
  • CoffeeScript has a core package
  • client/compatibility is pretty straightforward!
  • JSX
  • Angular has some build plugins that we should name drop here

Probably easy

  • SCSS/SASS - I imagine this will be fourseven:scss, pending the discussion here: Set up CI test service Meteor-Community-Packages/meteor-scss#133
  • NPM - the current solutions aren't ideal, but cosmos:browserify and meteorhacks:npm cover some variety of needs. I don't think we can currently recommend replacing the whole system with one of the community Webpack projects to meet this bullet point.

Need research

  • TypeScript - I've never tried using it with Meteor, but I've heard some people have success with it. I need to find out more.
  • Bower - I should find out more about the state of @mquandalle's bower. There's a PR here where a 1.2 transition is in progress: WIP: Port the package to the new Meteor 1.2+ Compiler API mquandalle/meteor-bower#94
  • Other templating languages - we should mention Jade and any other Blaze template compilers
  • CSS post-processors like autoprefixer. I don't know anything about this. @vladshcherbin have you done this before in Meteor?

Anything else I missed?

@vladshcherbin
Copy link

@stubailo I've used gulp to compile scss and pass through autoprefixer and it was very easy, just 2-3 lines and vendor prefixes were added to css files.

Then I saw there is no scss support in core and decided to give a try to fourseven/meteor-scss with autoprefixer inside. It worked well, but with 1.2 the build system changed and there is no more autoprefixer there. Here is the latest issue about that.

So, I decided to switch back to gulp until the build system will have stable scss and autoprefixer support. The Autoprefixer is absolutely a must in websites for me.

@vladshcherbin
Copy link

I don't know, if there is a way to do that now (post processing of css), but it is just a simple step in the build system - grab the css, push it through autoprefixer with options and store it.

It is available everywhere - gulp, grunt, webpack, etc.

@adrianbw
Copy link

An autoprefixer is absolutely necessary. We have several projects that we simply cannot upgrade to 1.2 until we have one.

@stubailo
Copy link
Contributor

we simply cannot upgrade to 1.2 until we have one.

What were you using before 1.2?

@mquandalle
Copy link

Not that some CSS pre-processors (such as mquandalle:stylus) include autoprefixer in the compilation step — not saying this is the best solution but it has been working very well for me.

@stubailo
Copy link
Contributor

@mquandalle we were having a parallel conversation here: Meteor-Community-Packages/meteor-scss#133

It seems like the best option might be to build it into the minifier? Although maybe if your stylus package works fine then it's a good approach for now!

@sebakerckhof was also considering having a separate branch with autoprefixer. But it seems somewhat silly to have everyone (stylus, less, scss) build in autoprefixer separately if we could do it once?

@adrianbw
Copy link

@stubailo Our projects are 1.1 right now (ignoring the one that's stuck at .7...).

@stubailo
Copy link
Contributor

@adrianbw I meant, what were you using for autoprefixing.

@adrianbw
Copy link

Ohhh, sorry. fourseven's package.

@stubailo
Copy link
Contributor

I'm really glad we found out about this whole autoprefixer thing. We now have a few issues in meteor/meteor about it:

meteor/meteor#5219
meteor/meteor#5512

I'd love if anyone could help with either.

@stubailo
Copy link
Contributor

@orefalo, @fullflavedave, can you tell me more about using TypeScript with Meteor? Is it something you are doing regularly? I'm mentioning you since you seem to be the main maintainers of this org: https://github.com/meteor-typescript

@fullflavedave
Copy link

I use TypeScript and the typescript-libs package every day in my current project, which I've been working on for well over a year. As you may have seen in the README, the definitions are obtained by parsing the Meteor data.js file and mapping/modifying some of the data. @D1no mentioned that he had been working on creating an integrated TypeScript compiler plugin using the definitions, but I'm not sure what the status is: https://github.com/meteor-typescript/meteor-typescript-libs/issues/25. Currently, I let WebStorm compile my TypeScript files into JS, although @orefalo created a compiler package that can be used.

@sebakerckhof
Copy link
Contributor

The Meteor-angular2 project (https://github.com/Urigo/Meteor-Angular2) seems to use this typescript compiler plugin: https://github.com/barbatus/ts-compilers

@orefalo
Copy link

orefalo commented Oct 27, 2015

Lack of time, I can't focus on the typescript compiler anymore. I heard the build system was changed in 1.2 but didn't find time to refactor the code just yet.

Please provide some context... what is the ask?

@stubailo
Copy link
Contributor

@orefalo I'm writing an article for the Meteor guide, which is supposed to be a resource that tells you most of what you need to know to write a Meteor app. I am wondering if it is feasible to write a Meteor app in TypeScript, and what kind of guidance I should give to an enterprising developer looking to do so.

@stubailo
Copy link
Contributor

@mquandalle how is Bower doing? I see the 1.2 branch is still open, but does it work well enough now? Or does it not work at all with Meteor 1.2? Also, what about Jade?

@D1no
Copy link

D1no commented Oct 28, 2015

@fullflavedave @stubailo though it is completely feasible to build a (solid) TypeScript compiler for .ts and .tsx files for meteor app and packages, we realised that we don't have a good answer how to handle the uni-module aspect of TypeScript (lazy loading etc). So instead of writing a complete module loader from scratch, we switched the ecosystem approach by using meteor with webpack and therewith npm.
meteor/meteor#4888 (comment)

The meteor TypeScript compiler, ideally, would implement the language service api of the native npm package so that running TypeScript in the IDE is not necessary (just for linting).

So there is currently no "native" implementation of TypeScript for meteor due to the unclear future of module management.

If you want to use TypeScript - which you should - I would advice to go for a webpack centered solutionwith the TypeStrong/ts-loader (for now): https://github.com/thereactivestack/meteor-webpack

@stubailo
Copy link
Contributor

OK, I posted an outline here: #67

@stubailo
Copy link
Contributor

@izakfilmalter, can you let me know about the tradeoffs between https://atmospherejs.com/seba/minifiers-autoprefixer and https://atmospherejs.com/juliancwirko/postcss in your app? We should make sure we can recommend something that works!

@izakfilmalter
Copy link

@stubailo for us the postcss is failing with our oath2 npm package we are using.

=> Started proxy.                             
=> Meteor 1.2.1 is available. Update this project with 'meteor update'.
=> Started MongoDB.                           
npm-container: updating npm dependencies -- express, oauth2-server, body-parser,
autoprefixer...
=> Errors prevented startup:                  

   While minifying app stylesheet:

   /Users/izakfilmalter/Projects/app/packages/npm-container/.npm/package/node_modules/oauth2-server/lib/oauth2server.js:35:28:
   No model supplied to OAuth2Server
   at new OAuth2Server
   (/Users/izakfilmalter/Projects/app/packages/npm-container/.npm/package/node_modules/oauth2-server/lib/oauth2server.js:35:28)
   at OAuth2Server
   (/Users/izakfilmalter/Projects/app/packages/npm-container/.npm/package/node_modules/oauth2-server/lib/oauth2server.js:31:47)
   at <runJavaScript-76>:130:49
   at Array.forEach (native)
   at getPostCSSPlugins (<runJavaScript-76>:129:37)
   at <runJavaScript-76>:194:17
   at Array.map (native)
   at mergeCss (<runJavaScript-76>:185:23)
   at CssToolsMinifier.processFilesForBundle (<runJavaScript-76>:156:18)


   While minifying app stylesheet:

   /Users/izakfilmalter/Projects/app/packages/npm-container/.npm/package/node_modules/oauth2-server/lib/oauth2server.js:35:28:
   No model supplied to OAuth2Server
   at new OAuth2Server
   (/Users/izakfilmalter/Projects/app/packages/npm-container/.npm/package/node_modules/oauth2-server/lib/oauth2server.js:35:28)
   at OAuth2Server
   (/Users/izakfilmalter/Projects/app/packages/npm-container/.npm/package/node_modules/oauth2-server/lib/oauth2server.js:31:47)
   at <runJavaScript-76>:130:49
   at Array.forEach (native)
   at getPostCSSPlugins (<runJavaScript-76>:129:37)
   at <runJavaScript-76>:194:17
   at Array.map (native)
   at mergeCss (<runJavaScript-76>:185:23)
   at CssToolsMinifier.processFilesForBundle (<runJavaScript-76>:156:18)


=> Your application has errors. Waiting for file change.

But everything works fin with https://atmospherejs.com/seba/minifiers-autoprefixer . I would prefer the postcss plugin because we can actually manage what versions of autoprefixer we are on and use postcss. But it seams to want to post process js files as css.

Once I remove the oath2 package I just get

for hours.

Note we do have 178 scss files. This is still using the old version of https://github.com/fourseven/meteor-scss with autoprefixer disabled. Compile time is less than 30sec normally for me.

@sebakerckhof
Copy link
Contributor

Well, any of those bugs in the postcss package should be easy to fix. I think the main difference between my package and the postcss package is that the postcss package is much more flexible, but requires more configuration to set up.

@izakfilmalter
Copy link

Ya @sebakerckhof with your package we have the same issue as the old https://github.com/fourseven/meteor-scss . It works turn key with little config, but we are dependent on you keeping up to date with autoprefixer. But with postcss, yes slightly more config, one more .json, but you get more control over your version of autoprefixer, and also can add any other postcss plugins you want to.

@juliancwirko
Copy link
Contributor

@izakfilmalter which version of the postcss package causes problems? With my quick tests it seems to work well. There isn't a bug with oauth2-server npm package. With fourseven:scss@3.4.1 too. (Of course I have only one .scss file for tests) Autoprefixer works on .css and .scss.

=> Started proxy.                             
=> Started MongoDB.                           
npm-container: updating npm dependencies -- express, oauth2-server, body-parser, postcss-import, postcss-nested, postcss-simple-vars, rucksack-css, autoprefixer...
=> Started your app.                          

=> App running at: http://localhost:3000/

There was an important fix in version 0.2.1 of the juliancwirko:postcss. Postcss now should know which npm package is a plugin and which isn't, but probably it could be done better. Maybe there are some corner cases.

@izakfilmalter
Copy link

I am on the newest version of your plugin @juliancwirko. I am still on fourseven:scss@3.1.1.

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

No branches or pull requests