search

dojo / cli

:rocket: Dojo - command line tooling.
http://dojo.io
Other
25 stars 34 forks source link

dojo build corporate - i.e. non FOSS build task #32

Closed rishson closed 7 years ago

rishson commented 8 years ago

@rishson commented on Wed Sep 07 2016

The app needs to have a proper build step that produces a production version that is compressed, minified (maybe inlined) and obfuscated.

@kitsonk commented on Wed Sep 07 2016

obfuscated

Why?

compressed

What did you have in mind for this? Usually compression happens via the HTTP server, right?

(maybe inlined)

What did you have in mind for this? Are you suggesting bundled/concatenated into a single file? I would say that we should have a build the produces at least a base plus at least one layer/dynamically loaded bundle to prove out the build theories.

@rishson commented on Wed Sep 07 2016

Yep - I'm just thinking of the classic build steps. You're right, compression should really be minification in this example. You'd want to obfuscate so its harder to 'borrow' parts of your app, and minifiy for perf reasons. I agree about creating a layer file to test the build.

@rishson commented on Wed Sep 07 2016

Later on, we can do more advanced build steps, image compression, sprite generation from base images (for app icons etc), css minification...

@kitsonk commented on Wed Sep 07 2016

You'd want to obfuscate so its harder to 'borrow' parts of your app...

While I understand the potential corporate requirements for such things, I find that in open source software, promoting such practices as morally objectionable personally. Of course people are going to use obfuscators, but I think it really sends the wrong message if we actively enable or promote such activities. We get our strength from doing these sorts of things out in the open, and while we have chosen licensing that doesn't "infect" others with our philosophy (e.g. the GPL), I would prefer not to condone such practices.

@rishson commented on Wed Sep 07 2016

Depends who the majority users of D2 will be. If corporates, then they would expect some kind of uglification, because their app won't be FOSS. The more philosophical question is "is D2 FOSS that helps people primarily write FOSS, or closed source?" We can be both, but the build should default to one or the other. FWIW, the only closed source build steps I can think of right now are uglify and add license header to built assets.

@rishson commented on Wed Sep 07 2016

Maybe the build defaults to FOSS and we add an extra cli module that targets closed source? It could uglify, add license, check dependency tree for incompatible licenses ...

@kitsonk commented on Wed Sep 07 2016

UglifyJS I have no issues with, as it isn't really an obfuscator, but a minifier... To quote:

UglifyJS is a JavaScript parser, minifier, compressor or beautifier toolkit.

Just because that code is hard to unpick is a side-effect, versus an intent. I also would expect our build process to generate source maps though that go back to the original source for debugging purposes.

As far as "is D2 FOSS that helps people primarily write FOSS, or closed source?", my response to that Dojo Toolkit has been, and will continue to be, focused on developing open source software, which has flexible licensing that does not hinder further commercial use. I don't think we need to make a statement about the primary target of solutions written in Dojo 2. It isn't a binary decision and in my opinion isn't required to provide context to the development of Dojo 2.

We have seen many commercial organisation be able to build viable commercial business by being wholly open with their software, including Microsoft and TypeScript which we have built Dojo 2 on. Promoting or enabling patterns of being closed is not in the wider interest of the community. Actively hindering commercial reuse though, is in my opinion as closed as being closed source.

There are plenty of commercial organisation that will sell obfuscation solutions to enterprises. They are much better placed to assist organisations wishing to do so than the Dojo Toolkit.

@rishson commented on Wed Sep 07 2016

uglify -mangle -compress is very much obfuscation. I'd agree on the sourcemaps though.

I'm fine with the default build being the best for FOSS, but still think there is a need for a more corporate focused alternative that does the tasks listed above + obfuscation. It could be as simple as:

> uglify -mangle -compress -banner 'Some copyright statement with year indicator set automatically'
> [some check for copyleft licenses in the deployed app's dependency tree]

@rishson commented on Wed Sep 07 2016

@kitsonk I'm going to split this issue (turn this into a dojo build corporate issue, and create another issue that is the immediate build steps for the example app.

rishson commented 7 years ago

Can be achieved with options available in existing webpack plugins - so closing in favour of doing in webpack.