divmain / js-seed Goto Github PK

I was reading about the future of npm and it's about to get crazy. The tldr; of the post is that npm is being broken apart into 3 modules: a registry, a cache and an installer in such a way that you could use BOTH Bower and NPM (of today)'s version of dependency resolution at the same time.

This is largely in response to the fact that lots and lots of people use NPM, a purposefully nody tool as a dependency resolution tool for projects that have nothing to do with node. They are moving to a "roll your own dependency system" to make it more flexible for projects that mix frontend and node. Interestingly the roll your own thing is what Express is doing too with Pilar.js in Express 5.

Anyway, the npm folks issued a call to action on the new plan which involves a few things - one of them is moving more config into your package.json. I thought I'd see what you thought about moving some of project.config.js into the package.json.

I noticed you're at v.0.6.0 but I'm not sure what your versioning scheme is.

One thought would be to leave it at 1.0.0 (the node recommended starting spot) and let it represent the state of the cloned seed project.

Another would be for that to be to have develop/stable or develop/master and version the project that way. You'd have to add a version clear line to the start.sh script.

Thoughts?

npm start will call gulp help

https://github.com/divmain/js-seed/blob/master/package.json#L53

https://github.com/divmain/js-seed/blob/master/gulpfile.js#L22-L24

There should probably be a big fat comment block explaining that new tasks should be created under ./tasks then required in the gulpfile. Projects with large gulp setups are too new to have established conventions so it might not be obvious.

I tried using js-seed to convert an old project from grunt -> gulp/webpack and forgot that the start script deletes my .git folder. I had recently pushed to master so I don't think anything was lost but this is a potentially big danger. If you need to do work like this on a branch you run the risk of losing a lot of work.

It's a new recipe on the Gulp site is the "blessed" way of sourcing tasks.

https://github.com/gulpjs/gulp/blob/master/docs/recipes/split-tasks-across-multiple-files.md

Right now 1/2 the gulp tasks are defined under tasks and the other half are composite tasks defined in the gulpfile. If you think it should be broken up maybe only the ones in the tasks folder shouldn't be exposed in the help list. Thoughts?

I think it might be better to have tasks/composite.js and then just reduce the gulpfile to just the require statements.

I came across this block in the test code which refers to some IE8 polyfil and I didn't really understand why it had to be there. Is this for the test runner? Probably worth documenting that tests won't run in old browsers if that's the case. On the frontend the only opinionated piece of frontend code is the inclusion of lodash which should go down to IE6 so I don't see any reason (other than the tests) the project wouldn't support down that far on that.

I was reading over some of the Clean Code book the other day and I'm starting to think that tasks/ may not be an appropriate name for the gulp tasks.

When Martin talks about clean functions he talks about how they should only have one level of abstraction. A bad piece of code has some high level concepts. For example a function that has a call to build a chunk of a page mixed in with low level details about adding/removing classes in a specific scenario. It mixes up the essential concepts with the details of doing something, which can be confusing.

The reason I think that tasks/ may not be the best name is that there is no context to tell you what a task is unless you already understand gulp and the strategy to break things up. For a person entering a codebase for the first time, cogent organization is very helpful.

Candidates for the directory name: gulp-tasks/, gulp/, build-tasks/

start.sh is amazingly helpful but its not clear from the docs what is going on. Maybe the README should have a section explaining start.

Introduce what is setup, how it is setup, and how it will benefit a new project.