1.0 RELEASE (tracking ticket)

[rvagg]

I've been a little sidetracked and haven't had much time to fiddle in the 1.0-wip branch but we need to get it sorted out and a new CLI released. (Thanks to @amccollum to prodding me into action here.)

This issue is an invitation for discussion what will constitute a 1.0 release. You're welcome to make suggestions but you're more likely to have success if you're willing to pitch in and help out.

Here are some items on the list of possible things that get included (some much more likely than others):

• **CommonJS module packaging _within_ bundled libraries**: i.e. being able to include multiple files for a single library and have `module.exports` and `require('./x')` work within library rather than just across separate libraries like it does now.

  This is the highest item on my wish list so it's going to get attention from me at least. More discussion can be found in Multiple includes with relative require()s #120 and as I've said there, my preference is for minimal-magic so rather than auto-discovery of `require`d files your _package.json_ should point to the files that are needed in your build, using optional globs to make it simple.

• **Allow for replacement of CommonJS with alternative bundling techniques**: I don't think there is a ticket for this but the idea here is that there is currently a strict link with [ender-js](https://github.com/ender-js/ender-js) as the "client lib" which manages CommonJS bundling plus adds the `$()` DOM collection stuff. CommonJS bundling is also hardwired into Ender, particularly 0.8 code. What I'd like to do is shift all of the CommonJS stuff out of the CLI and into the client lib and then make it possible to switch out the client lib with another that may bundle things differently; AMD perhaps.

  We're already part way there now in 1.0-wip as it accepts a `--client-lib` arg and we have templates doing a lot of the bundling. The next step would be to push the templates into the client lib so a different client lib could supply its own templates.

• **package.json extensions**: being able to override items in package.json so you can (1) provide additional bundling details to Ender and (2) override Node/npm items such as "name".

  More details in Proposal: Ender package.json extensions #131 and this item is mostly done in 1.0-wip, it just needs extra tests to clean up some bugs and possible add additional extensions (like adding recursive "externs" for Closure).

  As an aside, there's an interesting discussion on this topic over in [Bower](https://github.com/Adding support for specifying bower configuration in package.json bower/bower#62); mostly I disagree with the conclusions and I think it's working out fine in the new 1.0-wip code. but you're welcome to weigh in on the topic in Proposal: Ender package.json extensions #131 if you have an opinion.

• **Don't re-download packages for every *build***: a little like npm, it should be aware of what you have in node_modules/ and not download the same package every time you rebuild.

  This is already working in 1.0-wip and I'm using it in my build-process already and it's brilliant because Ender runs so much quicker. However, my feeling is that it's not quite right with package versions and tags, I wouldn't mind having feedback from others who have tried this out.

• **Sourcemaps**: thanks to @download13 for kicking this one off in Sourcemaps #141. While I'd really like this included in a 1.0 release I don't think it'll make it unless others want to step up and help get it sorted. It may have to wait for a 1.x release.

• **Include individual .js files in a build**: See Proposal: include individual .js files in build #139 for details, basically you should be able to just specify individual files in your _build_ command and have them included.

• **Support for alternative package repositories**: I'm thinking particularly of Bower here, see Support installing packages for alternative repositories #159 for details.

  I'm just not sure I'm enthused enough to put in the effort required to get this into a 1.0, I personally don't get what people have against npm for frontend packages--however I'd welcome anyone with strong feelings here to put up some code to make this work, it shouldn't be **too** hard in 1.0-wip as a lot of the repo stuff is abstracted away.

  One of the potential wins involved in doing this is wider acceptance in the frontend community but that largely comes down to subjective issues IMO.

There's probably other stuff I've forgotten and there's some other items that roll up into things listed above, I may update this list.

The aim here is to be able to split this up into workable issues and create a 1.0 milestone that can be used to track progress and hopefully push this baby out sooner rather than later.

[amccollum]

Seems like a good list, and I agree with your assessments on all of the proposed features.

[rvagg]

I've tagged a few issues with 1.0-blocker, you can track them here.

I'm going to put off sourcemaps and alternative repositories for now, they aren't high enough on my personal list to block a 1.0 release but they would be good to get done soon after. That doesn't mean that I wouldn't accept contributions for them from others for a 1.0!

I'm going to finish the work on the package.json extensions (#131) that I started but didn't finish, then probably move on the alternative bundling one (#164) as that will be quite interesting to play with. I'm also happy to help out with your work on #120 @amccollum as I have some ideas on that in my head that I should get out.

Happy to help anyone else get up to speed with contributing; ping me here if you want to help out.

[rvagg]

I'm struggling again to find time to allocate to this, I have a bit too much on my plate at the moment. Hopefully that'll clear up soon but I'm more than happy to see you forge ahead @amccollum! We need to get this beasty out.

[luk-]

Hey Rod, we spoke on irc earlier. Let me know if there's anything I can give a hand with to help push the 1.0 release forward.

[rvagg]

@amccollum is currently working harder on this than me as I'm a little overloaded with work. Andrew, perhaps you can tell us where you're up to and maybe push some code into the repo if you have anything to share yet? Is there anything in particular that you'd like help with or would like to delegate? I'm keen to get back onto this asap but life is a little hectic right now.

[amccollum]

Sorry for being out of touch, things are a bit hectic for me, too. My work on Ender got pulled into a little more of a drastic refactoring than I expected. I am hoping to separate and modularize the module mechanics, the repository backend, and the minification components of Ender, so that they can be treated as swappable plugins.

It would probably be best for me to at least submit a pull request for my separation of the common-js mechanics. I'll work on that today if I get a chance.

[rvagg]

Just push straight into the repo @amccollum, you should have access now. I'd like to resync with your work sometime, even if it's 1/2 broken. Feel free to make another branch if you prefer.

[luk-]

I'd be happy to test this out today or tomorrow if it gets pushed into a branch.

[amccollum]

I'm going to close this issue now that 1.0 (and also 2.0) have been released. Most of the issues outlined here are now either implemented, or have separate issues where discussion can continue.