Adopt build tool core and frontends?

[bebraw]

Hi,

Given it would be fairly simple to extract the core out of grunt-umd and make it a library of its own I started thinking perhaps the project would belong below umdjs.

It would look like this:

• umdjs/build-core - Streaming library used by actual build tools
• umdjs/grunt-umd - The plugin just moves under this namespace and uses `build-core´
• umdjs/gulp-umd - Gulp plugin, same core.
• umdjs/-umd - plugin, same core.

The primary advantage of having the tools below the same namespace would be discoverability. In addition it would add some credibility to the build tools and allow more people (umdjs team) to maintain them.

Does this sound reasonable to you? I understand if you are busy and prefer to keep tooling outside of umdjs but there are certain benefits as outlined above.

[adam-lynch]

👍

[addyosmani]

Does this sound reasonable to you? I understand if you are busy and prefer to keep tooling outside of umdjs but there are certain benefits as outlined above.

Please pardon our delay on replying to this. If you are still interested, I'm more than happy for it to exist under the same org and setup relevant privs for you to control the repo.

[bebraw]

@addyosmani No probs. Please take a look at https://github.com/bebraw/libumd . I've extracted the core there. It could use some tidy up and extra tests but it's getting there.

[dlebedynskyi]

there are couple of additional forks that use this UMD wrappers for builds.
One that I used earlier for my stuff is https://github.com/RReverser/pure-cjs. It has grunt builder https://github.com/RReverser/grunt-pure-cjs and gulp builider https://github.com/parroit/gulp-pure-cjs . You may want to looks at those

[bebraw]

@addyosmani Bump. Would you like to adopt https://github.com/bebraw/libumd ? It's complete for my purposes and see no harm in moving it below umdjs org as that's a better home for it.

[EvanCarroll]

There is clearly a group of people that like this. I'm going to take a look at this and provide some input. Give me a week. The interesting thing going on here, from my perspective, is that default templates can be updated easily and packaged separately. That's a killer advantage.

[EvanCarroll]

@bebraw would libumd be able to reproduce the templates? Would it be possible to say run both of them through an uglify pass (which should remove comments and other crap), and then md5sum the output of libumd, and the templates/ directory to see if the same code is produced?

[bebraw]

@EvanCarroll Essentially libumd does just a fancy replace operation through Handlebars. I suggest giving it a go to see if it fits your purposes. Since my previous comment here it has evolved a little bit (better tests, more features) and I consider it somewhat feature complete.

[EvanCarroll]

Sure, I agree. My concern is primarily with drift between libumd and umd if adopted by umd. I'm wondering how we can mitigate that concern. A simple method would be to have a test that UMD is outputting the same code found in the template itself. If there is a problem with the build order, or something is rewritten in a template I want to know libumd is out of sync ASAP if adopted by the umd project. Ideally, we'd adopt your code and make you the primary admin. But, issues filed in compatibility would continue to pop in umdjs/umd.

[bebraw]

@EvanCarroll We would need some kind of an executable specification. We might want something that tells us whether a file passes the specification or not. If we had that, then you could test libumd output against that.

I agree getting out of sync would be a serious problem. That's why it might be ideal if you could test the library against the official specification without a great hassle.

I feel the specification and the library may have to move closer to each other somehow to make this work. Note that the current test suite runs against different targets to test various UMD paths. I'm not saying it covers the whole specification as there are quite a few variants.

Essentially we want just to assert that given certain input and UMD template, we get certain output through UMD branches. If the specification can become something like that, you could run libraries like libumd directly against it.

Just my two euro cents. :)

[EvanCarroll]

Essentially we want just to assert that given certain input and UMD template, we get certain output through UMD branches. If the specification can become something like that, you could run libraries like libumd directly against it.

The specification is the template. We can write it in English, but that doesn't actually solve the problem. There seem to be two ways to solve the problem:

1. Minify/uglify, and try to generate the same Javascript passing a checksum.
2. Provide every combination of environment in a test (which will have to be run in Node.js) and make sure the same branch is hit in both the test and the template.

The second idea is better. It's actually doing the work. But, that's my only personal hold up to putting libumd under umd/libumd.

[bebraw]

@EvanCarroll How do you want to proceed with this? Take a good look at my existing test suite. Perhaps that's a starting point for 2.

[valerii-zinchenko]

Hi everyone! Any updates on this?

Below are my points of view.

libumd and umd

I also think, that umd and libumd projects should live together, especially when @bebraw himself proposed to move his library here.

The advantage of this would be the better specification for UMD by taking into account the experience of both projects. The templates from both projects are similar, but not 100% equal, or to be more accurate the specifications of both projects are not 100% equal.

Also, I think, it would be better to give to the world a wrapper library, which can be integrated anywhere, because, it looks for me, that people doesn't know about libumd. They just copy some template they need into own project and adapt it for own requirements. Then on regular bases they need to find a time to sync theirs template with the updates umdjs/umd project. This is not nice.

Template as a specification

I am not fully agree with the point to use template as a specification. Template is just a code wich has some logic behind it, but it doesn't reflect why that logic is written so, i.e. what was the requirement to write some part of code that way.

I found for myself few pieces of code in the templates, that I don't really understand why it was written so. So I tried to find the commit for that line in hope to find some explanation to that. I found that commit, but commit message was not enough for me, so I tried to search for pull request in hope to find more detailed explanation there and I finally found that.
Another good example to the previous story is that if some non-logical change was done, for example occasionally some extra space was added, or indentation was changed. It increases, the searching path.
I think, that is a main problem to keep code as a specification. It can be really hard to find the root/specification for that line.

The similar reason to not keep code as specification is for testing. I assume, that when you see some PR, you runs a lot of tests in your mind to verify, that that change is not breaking the previous implementation. It means, that everyone, who is reviewing the PR should know all that test cases.

Having a specification as a text would be easier to describe each word and the statement of the code and would be a great reference for tests (in-mind tests and unit tests)