Modularized JavaScript code in Jenkins Core .... how about it?

[Tom Fennelly]

There are a few changes being proposed/planned for Jenkins Core that will require some UI changes e.g.:

1. Unbundling plugins. See dev list thread. The UI changes here would be a new "Plugin Selection Wizard" to help new users of Jenkins get up and running quickly, filling the gap left after removing the currently bundled plugins.
2. Hopefully making improvement to the config pages ala what KK and Gus Reiber are doing on the config-ui-changes branch.

In order to implement these changes as hoped, we're going to need to use client-side JavaScript (better UX etc). At the moment, in Jenkins, JavaScript is a bit of a mess. It would be nice to start addressing this problem in some way under the assumption that, going forward, we can make more use of client-side JS for better UX, but do it in a more maintainable way (Vs everything being in hudson-behavior.js).

Some of us at CloudBees have been developing and using some patterns and tools to help build Jenkins plugins that have GUI elements that make better use of modularized JavaScript (using CommonJS modules etc). We think it has worked quite well and would be keen to reuse some of the same techniques and tools in Jenkins core if possible.

One of the tools we developed to help us assemble these JavaScript components is a build time utility we call jenkins-js-builder. It's an NPM utility for assembling CommonJS module "bundles", built on Gulp, Browserify and more.

My question .... would there be community objection to introducing something like this into Jenkins core? We're not trying to suggest it as a silver bullet for all JS related issues, but we do think it would help improve things.

Regards,

T.

[Tom Fennelly]

Something that might help ... a description of the state of JavaScript in Jenkins as we see it.

[Surya Gaddipati]

Hi Tom,

I've been packaging all kinds of js stuff with webpack. Avoids all kinds of problems with globals ect that you described. 

 I am not quite sure if we need to invent a jenkins specific solution here. 

Here is an example using elm 

https://github.com/DotCi/DotCiPipelineViewer 

example using react and co

https://github.com/groupon/DotCi 

None of those leaks globals.

Surya

[Tom Fennelly]

Hi Surya. We're not inventing anything new for the bundling/packaging part. It uses Browserify for that, which is similar to Webpack.

So you are not against the idea of adding build steps to Jenkins core re supporting modularised JavaScript?

Sent from my iPhone

--
You received this message because you are subscribed to a topic in the Google Groups "Jenkins Developers" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/jenkinsci-dev/0wu31f3az_w/unsubscribe.
To unsubscribe from this group and all its topics, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/6948e86e-7313-44f9-93cd-ea6b42158093%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Robert Sandell]

What about the existing adjunct support in stapler?
That is meant to work as treating js, jelly et.al packages as maven modules.

See for example https://github.com/stapler/stapler-adjunct-bootstrap, https://github.com/stapler/stapler-adjunct-jquery and https://github.com/stapler/stapler-adjunct-underscore

/B

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/0B84D67D-5876-4BFC-ACA7-DDEE85F817D2%40gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

Robert Sandell

Software Engineer

CloudBees Inc.

[Stephen Connolly]

My main concern is that we do not introduce a build tool that makes it even more complicated to build Jenkins behind a corporate firewall, as that could significantly impact some of the contributors.

While this is not something that personally affects me in my day job, it would have made it extremely difficult to make my initial contributions during the 2006-2011 period when I was behind a corporate firewall (absence the hacking on public transport).

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS2OYYm_1KFzpJgSLRc2TJcWqyQ9ULjAmmRzqMbwdpyuOw%40mail.gmail.com.

[Tom Fennelly]

I'm not sure what the questions is, but, module bundles can be loaded as adjuncts too. That's not a problem.

The bootstrap and jquery stapler adjunct examples you gave there are exactly the type of thing we should be trying to get away from i.e. globally scoped framework libs.  jenkinsci/js-libs has a number of these bundled in a way that makes them non global (which means we can deprecate, update etc these libs in a safer way that's not possible with the old globally scoped adjuncts). As for using libs like underscore ... you can just use standard node/NPM install and "require" them in your CommonJS modular code.

On 7 September 2015 at 08:51, Robert Sandell <rsan...@cloudbees.com> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CALzHZS2OYYm_1KFzpJgSLRc2TJcWqyQ9ULjAmmRzqMbwdpyuOw%40mail.gmail.com.

[Tom Fennelly]

It seems inevitable to me that improving the Jenkins UI will involve changing how things are done today and that's going to involve introducing something else into the mix. There's no doubt that introducing something else into the mix can make life more difficult in some situation. I suppose the question is, do we think the pluses outweigh the minuses?

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BnPnMwgccHVSq1BrKNjSJrxZRhKFbhzo0y6CYp%2BaYwG-05BKw%40mail.gmail.com.

[Robert Sandell]

Well, as a non js dev when I read the word "bundle" I associate it with "a packaged versioned unit that is easily distributed and deployed". I didn't get that it was the globally scoped libs you wanted to get rid of, I read it as the other way around :)

/B

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BbPaoK3-dfdEwzKk%3D_nNfWpJepPpiWrpwLNykYDy4HuRwYY%2Bg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Robert Sandell]

Well, in my experience NPM is notorious for not working well with proxies. But maybe that has been fixed in the year and a half since I heard the cries of my developers last :)

/B

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CA%2BbPaoLQpv_SEwbE7n-jX%2BU1U4TZ7rPD8EqAXz3DTMVHxdw0bw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

[Tom Fennelly]

On Monday, September 7, 2015 at 9:43:16 AM UTC+1, Robert Sandell wrote:

Well, in my experience NPM is notorious for not working well with proxies. But maybe that has been fixed in the year and a half since I heard the cries of my developers last :)

I'm not sure what problem they had, but I do know that the proxy config can be set.

[Michael Neale]

well that was then... I am sure there are some theoretical contributors that could be bitten by not having internet access (or a corporate proxy - kinda the same thing right?), but if they are, then the tooling should be fixed/adjusted so it does work for them as needed in a reactive way, not by leaping to conclusions. The tide of change can't be held back for ever. 

I think Surya is a great example of a contributor that I assume would not be affected by this, in fact, using tooling that is far out of step with the rest of the world (ie, only ever used in jenkins) would act as more as an obstacle than other things on the whole. 

[Michael Neale]

I think the general view is npm is notorious in general ;) 

In its defence it has done a reasonable job of embracing windows users in the past, and oft neglected community of developers (I know I all too easily neglect them). 

[James Nord]

Can we make sure that the jenkins artifactory will be used to download these js packages and store them forever (otherwise I am -0.5).

without that we could be up the proverbial creek when someones hosting decides to depart / change url etc. etc... (seen it way to often with maven).

so long as I can mvn install without installing extra tools and remembering to set all the specific environment variables then I have no other objections - but to be fair I'm not exactly sure of all the ins and outs of the JS packaging here anyway

[Tom Fennelly]

On Monday, September 7, 2015 at 1:02:13 PM UTC+1, James Nord wrote:

Can we make sure that the jenkins artifactory will be used to download these js packages and store them forever (otherwise I am -0.5).

without that we could be up the proverbial creek when someones hosting decides to depart / change url etc. etc... (seen it way to often with maven).

There are private NPM registries that can be configured and installed, including via artifactory (it would seem).

 

so long as I can mvn install without installing extra tools and remembering to set all the specific environment variables then I have no other objections - but to be fair I'm not exactly sure of all the ins and outs of the JS packaging here anyway

As things stand, "mvn install" would handle everything without any additional setup by the developer. The only time you might want to perform local setup is if you are going to work on this stuff (modular JS etc).

[Kohsuke Kawaguchi]

I want to second this proposal as a great progress for us. It reuses a lot of existing projects and tools from NodeJS, and allow small modules of JavaScripts to refer to each other more easily and in a "standard" fashion, compared to adjuncts.

I see this as a key step to enable extensibility in the frontend.

--

You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/9f36b348-aacc-4fbc-85f6-ea6761e9cb22%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Kohsuke Kawaguchi

[Robert Sandell]

Yes I agree, let's do this!. It might even get some more front end developers into the project if they find the tooling somewhat familiar.

I just misunderstood Tom's proposal at first :)

/B

To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAN4CQ4xr_YG%3DDPZV3nkRbNivb-xuKo7CSO%3Dyb8xLSNNqLHspTQ%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--