I believe using a prefix like "-gjs" might work. I'm planning on making
GULP run on GJS, so I can simply "require" jasmine-gjs and run it from
there.
Regards.
On 06/12/17 12:19, Andrea Giammarchi wrote:
or considering latest adventures in JS land and extensions:
jasmine.gjs 😄 why not
On Wed, Dec 6, 2017 at 11:03 AM, Andrea Giammarchi
<andrea.giammar...@gmail.com <mailto:andrea.giammar...@gmail.com>> wrote:
+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
<mailto: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
<mailto: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/Makefile.am#L596-L599
<https://github.com/endlessm/eos-knowledge-lib/blob/master/Makefile.am#L596-L599>
Regards,
Philip C
On Tue, Dec 5, 2017 at 12:59 AM Edgar Merino
<donvo...@gmail.com <mailto: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
<https://github.com/babel/babel/issues/4480>
I wonder if using
https://github.com/WebReflection/babel-plugin-transform-builtin-classes
<https://github.com/WebReflection/babel-plugin-transform-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 <mailto: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 <mailto: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
<mailto:javascript-list@gnome.org>
https://mail.gnome.org/mailman/listinfo/javascript-list
<https://mail.gnome.org/mailman/listinfo/javascript-list>
_______________________________________________
javascript-list mailing list
javascript-list@gnome.org
<mailto:javascript-list@gnome.org>
https://mail.gnome.org/mailman/listinfo/javascript-list
<https://mail.gnome.org/mailman/listinfo/javascript-list>
_______________________________________________
javascript-list mailing list
javascript-list@gnome.org <mailto:javascript-list@gnome.org>
https://mail.gnome.org/mailman/listinfo/javascript-list
<https://mail.gnome.org/mailman/listinfo/javascript-list>
_______________________________________________
javascript-list mailing list
javascript-list@gnome.org
https://mail.gnome.org/mailman/listinfo/javascript-list
