Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
rishson opened this issue Sep 7, 2016 · 10 comments
Closed

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

rishson opened this issue Sep 7, 2016 · 10 comments

Comments

@rishson
Copy link
Contributor

rishson commented Sep 7, 2016

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

@rishson rishson added this to the 2016.09 milestone Sep 7, 2016
@kitsonk
Copy link
Member

kitsonk commented Sep 7, 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
Copy link
Contributor Author

rishson commented Sep 7, 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
Copy link
Contributor Author

rishson commented Sep 7, 2016

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

@kitsonk
Copy link
Member

kitsonk commented Sep 7, 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
Copy link
Contributor Author

rishson commented Sep 7, 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
Copy link
Contributor Author

rishson commented Sep 7, 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
Copy link
Member

kitsonk commented Sep 7, 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
Copy link
Contributor Author

rishson commented Sep 7, 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
Copy link
Contributor Author

rishson commented Sep 7, 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 rishson changed the title Non-functionals dojo build corporate - i.e. non FOSS build task Sep 7, 2016
@rishson rishson removed this from the 2016.09 milestone Sep 7, 2016
@rishson rishson removed the bookstore label Sep 7, 2016
@rishson
Copy link
Contributor Author

rishson commented Sep 7, 2016

Issue moved to dojo/cli #32 via ZenHub

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants