+1 for using npm as the repository for GJS, which is the #1 reason for CGJS to exist.
I wonder if, being this potentially the beginning of a new way to share GJS modules, we should agree in a convention to make it clear to the rest of JS community what is the module target. As example, naming all GJS modules as `gjs:jasmine` or `gjs-jasmine` or ... `gjs/jasmine` .. or ... suggestions / opinions welcome :-) On Wed, Dec 6, 2017 at 10:43 AM, Edgar Merino <donvo...@gmail.com> wrote: > Hello Philip, I was thinking on making the jasmine-gjs available through > NPM, so including it should be as easy as adding it to the package.json of > the project. I'll report my progress on this. > Using docker with travis however should help with the dated gjs found > under ubuntu tasty, I'll give that a try too. > > Regards! > > El 6 dic. 2017 12:07 AM, <philip.chime...@gmail.com> escribió: > >> Hi, >> >> This is really cool! Thanks for sharing it. >> >> For reference, the alternative approach I've always used with jasmine-gjs >> is to integrate it with configure/make [1]. >> >> Travis's default Ubuntu images are quite old. They have more recently >> enabled using Docker images, but you'd probably have to take a Fedora 27 >> image or similar, write a Dockerfile to install jasmine-gjs, and publish it >> on your own account in DockerHub or something like that. I haven't looked >> into this yet. >> >> [1] https://github.com/endlessm/eos-knowledge-lib/blob/master/Ma >> kefile.am#L596-L599 >> >> Regards, >> Philip C >> >> On Tue, Dec 5, 2017 at 12:59 AM Edgar Merino <donvo...@gmail.com> wrote: >> >>> Hello, I've updated the repository for the extension, Karma is no longer >>> used for testing, jasmine-gjs is used instead. This is even working with >>> Travis CI (although it runs on a pretty dated gjs version, 1.40). >>> Transpiling should now be optional, and testing is a lot let hackish (e.g. >>> you no longer need a full browser implementation like PhantomJS and Karma) >>> and it's running under native GJS. >>> >>> Webpack is still used, which requires a build step before testing to >>> generate a single test UMD module. This makes executing a single test file >>> impossible right now, they all have to be executed at once. >>> >>> Using Andrea's cgjs, webpack can be avoided, it'll make all NPM modules >>> available in a more native way. Also, tests can be run individually, which >>> is an added benefit. >>> >>> Next step would be to give cgjs a try to use require instead of the >>> native imports mechanism of GJS. >>> >>> Regards. >>> >>> On 04/12/17 20:02, Edgar Merino wrote: >>> >>> Hello Andrea, CGJS looks promising, it actually solves what I was >>> missing/patching, and it can be easily integrated with WebPack (which in >>> turn provides ES6 imports through UMD, if needed/preferred). >>> >>> To eliminate transpiling completly when testing, currently you can use >>> firefox, but a better option would be something like jasmine-gjs. I'll give >>> this a try and report back, this should also eliminate the dependency on >>> Karma, which is mostly a hack here, but there's got to be some work done to >>> integrate that with webpack (needed mostly for ES6 imports). >>> >>> I'll see if plugin-transform-builtin-classes helps, thanks for the tip! >>> >>> Regards. >>> >>> On 04/12/17 19:15, Andrea Giammarchi wrote: >>> >>> Babel transpiling builtins is broken since ever: >>> https://github.com/babel/babel/issues/4480 >>> >>> I wonder if using https://github.com/WebReflection/babel-plugin-transfor >>> m-builtin-classes would help >>> >>> Also please have a look at cgjs which brings CommonJS to GJS: >>> https://github.com/cgjs/cgjs >>> >>> Regards >>> >>> On Mon, Dec 4, 2017 at 8:45 PM, Sriram Ramkrishna <s...@ramkrishna.me> >>> wrote: >>> >>>> I'm going to defer to someone like Phillip Chimento who knows this >>>> stuff way better than I do. However.. >>>> >>>> >>>> On Mon, Dec 4, 2017 at 2:54 PM Edgar Merino <donvo...@gmail.com> wrote: >>>> >>>>> I've posted a similar email to the GSE mailing list, but I thought >>>>> it would be helpful for any GJS developer looking to create quality code >>>>> by >>>>> applying TDD. >>>>> >>>>> It'll be great to read your thoughts on this approach. >>>>> >>>>> >>>> Thank you for putting the effort into doing this. This is pretty neat >>>> concept. At one point, a couple years ago I was trying to figure out how >>>> to do testing on extensions as a whole as part of the release process. The >>>> test was a basic "Does it work?". But having a mechanism to do unit tests >>>> would be pretty handy especially if it could be incorporated as part of the >>>> submission process. So from a policy perspective I think this is pretty >>>> awesome. >>>> >>>> sri >>>> >>>> >>>> _______________________________________________ >>>> javascript-list mailing list >>>> javascript-list@gnome.org >>>> https://mail.gnome.org/mailman/listinfo/javascript-list >>>> >>>> >>> >>> >>> _______________________________________________ >>> javascript-list mailing list >>> javascript-list@gnome.org >>> https://mail.gnome.org/mailman/listinfo/javascript-list >>> >> > _______________________________________________ > javascript-list mailing list > javascript-list@gnome.org > https://mail.gnome.org/mailman/listinfo/javascript-list > >
_______________________________________________ javascript-list mailing list javascript-list@gnome.org https://mail.gnome.org/mailman/listinfo/javascript-list
