+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 <donvodka 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.
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.
On Tue, Dec 5, 2017 at
12:59 AM Edgar Merino <donvodka 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!
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.
