Use a version of ngrok which runs on recent versions of Windows and MacOS.
Switch to using the npm `overrides` property, to avoid needing to mantain a separate fork of `zuul-ngrok`
Had obviously been forgotten, but those test files should have been part
of the ordinary lint phase.
The fact that we had forgotten to lint these files, allowed a missing
semi-colon to sneak into `./test/cli-test.js` file.
Refs https://github.com/janl/mustache.js/pull/777
By showing explicitly how/where `Mustache` comes from in that
specific scenario, where CommonJS is assume to be available,
either provided by Node.js or a build tool like webpack etc.
For the record, it could also be `import` if the using project
uses ES Modules, as we've recently exposed native ES Modules
support as well.
These changes adds an `exports` field to package.json with the main
goal of allowing the root/main export to be our ESM syntax version of
the package, as opposed to the UMD/CommonJS version.
This will make it easier for using projects written with ESM to use
mustache.js out of the box, without having to figure out that they'd
have to `import mustache/mustache.mjs` to get the ESM version.
It is also assumed to be beneficial for tools like http://skypack.dev
to choose the correct ESM version when appropriate.
Refs https://nodejs.org/api/packages.html#packages_package_entry_points
Noteworthy tweak is the fact that it seems `zuul` are eagerly loading
all `require('whatever-package-or-path')` it sees before pushing the
contents to Saucelabs.
That was troublesome because we don't want the `esm` package to be
loaded when running browser tests. But it was, even though we loaded
`esm` conditionally after checking the current Node.js version used.
The trick was to not use `require('esm')` but `module.require('esm')`
instead, to fool the assumed look-out for `require` somewhere inside
`zuul`'s code.
Because the source code is written in ESM syntax and we cannot use the
`esm` package to make `require()` ESM compatible, since that package
does not support legacy versions of Node.js.
Also in our usage tests in CI, we need to mimck the npm packaging
behaviour where building is involved.
Because `esm` does not support legacy versions of Node.js, at least not
below Node.js 6 as of writing this, we have to avoid using that whenever
tests are running on legacy versions.
But now that the source code (`mustache.js`) is written in ESM syntax,
how on earth are we going to run tests on these legacy versions of
Node.js? We gotta run the build step first, so that we end up with a
`mustache.js` file in CJS, or strictly speaking it will be UMD.
That's kinda pain in the backside isn't it? Yes, but running tests on
legacy versions are not meant to be done locally, but rather in CI. That
means we can easily automate the flow of (1) building the source code
before (2) starting the test suite.
For our futureselves, if we want to stop running tests on legacy
versions of Node.js; the changes introduces in this commit, could be
removed completely.
These changes are primarily aiming for having an acceptable developer
experience when working on changes locally and want to run the test
suite.
By using `esm` as a required package to be executed *before* the
individual test files are executed, `esm` allows CommonJS/`require()`
based code to use code written with ES Modules syntax.
In practise that means our existing CommonJS based test suite that is
`require()`ing the source code witten in ES Modules, is seamless and
totally transparent. It just works without any build or transpiling
pipeline like `babel` involved.
Caveat: the `esm` package only support Node.js 6.x and above.
That is more than okey, as we've got continous integration to verify
how our changes works on different versions of Node.js, browsers & deno.
Refs https://www.npmjs.com/package/esm
Primarily because installing `git` hooks are easy to forget for
maintainers, whilst telling `npm` to do something as a consequence of
`$ npm version <patch | minor | major>` is seamless.
Also worth mentioning we what we used to do in the pre-commit hook
script is now greatly simplified as we don't want to have the build
output and/or the `.min.js` in git anymore.
Therefore, as long as we've bumped the version number in the source
code, we're basically done, after having amended that change into the
git commit the `npm` CLI creates.
Although we'll now end up with only `mustache.js` in the git repo,
being written in ESM syntax, the npm package will still be as before:
- `mustache.js`: UMD, meaning CommonJS, AMD or global scope
- `mustache.mjs`: ESM
There has not been activity there for several years. No point in
actively inviting potential using developers in there, instead of
just using what we have on GitHub.
None of the recent maintainers has remembered trying to keep the
nuget.org package up to date.
As of writing this, it's over 7 years since the last mustache.js
version got published on nuget (v0.7.2).
Adding to that, there has been no questions asked from the nuget
community about outdated versions.
With the above in mind, we'll remove the nuget spec from our repo
since it only adds to confusion at this point.
Refs https://www.nuget.org/packages/mustache.js/
No need for X amount of different Node.js version to all run the linting
as part of their CI rutine. Easier to just run that once, completely
separate from the unit tests.
Removes running Node.js 10 & 12 from Travis CI as we do that with
GitHub Actions as well.
The only reason we still keep Node.js 8 running on Travis CI is due to
the browser usage testing we've setup, with encrypted secrets and all.
Ideally we'd move those browser tests to run via GitHub Actions for
consistency with the rest of our tests, but postponing that work
for now as it's not critical.
As seen from the test run log:
```
$ deno test --allow-net=deno.land test/module-systems/deno-test.ts
Compile file:///home/runner/work/mustache.js/mustache.js/.deno.test.ts
Download deno.land/std@v0.51.0/testing/asserts.ts
Warning std versions prefixed with 'v' were deprecated recently. Please change your import to deno.land/std@0.51.0/testing/asserts.ts (at deno.land/std@v0.51.0/testing/asserts.ts)
error: Uncaught Error: Import 'deno.land/std@v0.51.0/testing/asserts.ts' failed: 404 Not Found
at unwrapResponse ($deno$/ops/dispatch_json.ts:43:11)
at Object.sendAsync ($deno$/ops/dispatch_json.ts:98:10)
at async processImports ($deno$/compiler.ts:736:23)
```
The `render` argument passed to a `function (text, render)` lambda function was not accounting for custom tags or other configuration. This issue has been fixed and a regression test has been added for this case.
If an object is provided for what used to be the `tags` argument instead of an array, then the object is treated as a "config" object. A config object can have a `tags` attribute which behaves the same as the `tags` argument, and it can also optionally have an `escape` argument that is used for providing a custom escape function for that render call. The rationale for this addition is that providing an escape function here, when rendering a template, is a safer pattern for specifying an escape function than modifying the global mustache.escape attribute when a project may need to use mustache to render more than just one kind of content, e.g. both HTML and Latex templates in the same project.
Windows shell does not recognize 'single quotes' the same way as bash. The 'single quotes' in the build command have been changed to "double quotes" instead.
These changes optimizes the performance of escaping number
values, by not passing them through the ordinary HTML escaping
that is done on string values.
In the spirit of keeping the public API of mustache.js as small as
possible for maintainence reasons, the undocumented and un-tested
`.to_html()` method is removed.
The functionality involved, where it can rather invoke an optional
function provided with the result of `.render()`, instead of returning
it as a string like `.render()` does, is something that using projects
very easily can do themselfs -- it does not have to be provided by
mustache.js.
Blooper introduced when making the usage examples in README.md
more modern a couple of days ago, where the example fetching the
mustache template over HTTP, didn't in fact use the fetched template.
Since TypeScript usage has exploded the last years but this is
package is written in JavaScript, we might at least reference
the external DefinitelyTyped package @types/mustache that has
a somewhat up-to-date set of type definitions for most of the package.
Primarily because the these sections were very given a lot
of attention, high up in the README, where ideally usage and
basic syntax should have priority.
More and more of the community seems to be encouraging use of
zero-dependency packages. We might as well point that out early
on in our README since that's how mustache.js always has been
and planned to be going forward.
Luke Blaney
Taha Shieenavaz
Pietro Menna
Phillip Johnsen
Mejia1994
Nate Sire
Trevor Manz
Sophie Kirschner
Pierre Carru
Frieder Bluemle
urain39
Tim Gates
Ricardo Aielo