sir-dunxalot / ember-cli-modernizr

Parses your Ember CLI app for Modernizr references and creates the smallest possible Modernizr build
MIT License
11 stars 1 forks source link

Server hangs in development with shouldParseFiles enabled #5

Open markmhendrickson opened 8 years ago

markmhendrickson commented 8 years ago

This may be due to confusion on my end about how this addon works in general and the shouldParseFiles property in particular, but when I enable that property in development so I can test how different browsers variably generate classes on the html tag based on their feature support, my Ember server hangs indefinitely upon page load.

I'm also unable to kill the server normally with ctrl + c when it hangs and have to instead suspend then kill separately with kill.

When I set shouldParseFiles to false or simply omit it from my build config, pages load as expected but the classes don't vary between browsers. (Note that I'm specifically looking to detect variable support for "backdropfilter" between Safari, which supports it, and Chrome, which doesn't. Curiously, neither "backdropfilter" nor "no-backdropfilter" appear as classes despite its appearance in the Modernizr docs: https://modernizr.com/docs).

Am I correct to attempt setting shouldParseFiles to true in dev to test between browsers, and if so, is it unexpected behavior for the server to hang as a result? Or am I missing a piece?

As you can see below, my build config is clean apart from the Modernizr config:

/*jshint node:true*/
/* global require, module */
var EmberApp = require('ember-cli/lib/broccoli/ember-app');

module.exports = function(defaults) {
  var app = new EmberApp(defaults, {
    modernizr: {
      shouldParseFiles: true
    }
  });

  return app.toTree();
};
sir-dunxalot commented 8 years ago

Thanks for the explanation. It sounds like unexpected behaviour. I have a couple of questions:

shouldParseFiles is a core concept of this library - it exists to automate detections for which Modernizr tests are required in the prod modernizr.js build by looking at places you've included references to Modernizr in your JS and CSS. The typical use case is to set as false in development (so we just have every Modernizr test available for you and make rebuilds quicker) and then to set it as true for prod builds so the vendor file size is optimized.

Thus, it will be important to find out what has caused this regression in functionality.

sir-dunxalot commented 8 years ago

I think the addon will need an update for the latest Ember CLI and it's clearly not documented either, though tests exist. This could be a good opportunity to push the addon into the mainstream and make a stable release.

markmhendrickson commented 8 years ago

Thanks for the quick reply! And for creating this addon.

I'm using Ember CLI version 2.5.1 with Node version 4.0.0 on OS X 10.11.5. And I've let it hang for several minutes before killing the server.

I'm not too clear on how the library parses JS and CSS to build Modernizr but my feeling here is that it'd be elegant for it to automatically know whether a re-build is necessary, perhaps by detecting specific file changes, instead of having to flag it manually for parsing. But I don't know the intricacies involved, so that's wishful thinking on my part =)

sir-dunxalot commented 8 years ago

So I can tell you that it's not very elegant haha. It uses node filesystem's methods, like Ember CLI and Broccoli does under the hood, but there's nothing fancy optimizing when to re-build, etc. It just hooks onto whenever Ember CLI say to rebuild.

I'd loved to figure out really efficient ways to run this addon. Unfortunately, I don't have as much time as I used to get up-to-speed with the server-side of things. On the plus side, at least the primary use case for shouldParseFiles is mainly for prod builds only.

My first goal here will be to get the addon functioning and documented and then maybe we can persuade someone with a working knowledge of the filesystem to help optimize this.