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
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 `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
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.
These changes allows the internal template cache to
be customised, either by disabling it complete or
providing a custom implementation of how templates
are cached.
To ensure the ES module and source exposed by this package is compatible
with Deno going forward.
Added benefit is we get some sanity checks of the source code for free
due to Deno's built-in TypeScript compiler getting angry if it sees
things that does not make sense, in terms of missing function arguments
and so on.
This is a precursor to introducing a build step that will change what
we expose from this package. Better off writing some tests to verify
existing projects with different module systems continue to work as
expected.
This is a precursor to introducing a build step that will change what
we expose from this package. Better off writing some tests to verify
existing projects with different module systems continue to work as
expected.
This is a precursor to introducing a build step that will change what
we expose from this package. Better off writing some tests to verify
existing projects with different module systems continue to work as
expected.
In an effort of ensuring consistent code style in test files as with
the "production" source code, we should run eslint as part of the
`$ npm test` script as well.
Most of the related fixes was done by `eslint` using the `--fix` argument.
Only special configuration tweaks for tests compared to the other
source code, is to allow functions declaration without names. The
rationale for allowing that in tests, is that the important reason we
have them in the source code (proper stacktraces) aren't as important
in test files.
Fixes this failure:
1) Mustache CLI without partials writes rendered template into the file specified by the third argument:
Uncaught TypeError [ERR_INVALID_CALLBACK]: Callback must be a function
at makeCallback (fs.js:136:11)
at Object.unlink (fs.js:943:14)
at test/cli-test.js:86:12
at ChildProcess.exithandler (child_process.js:285:7)
at maybeClose (internal/child_process.js:982:16)
at Process.ChildProcess._handle.onexit (internal/child_process.js:259:5)
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
* prevent value from being returned by Context.prototype.lookup if lookupHit is false
* add test for renderability of Array.length via dot notation
* Remove `typeof obj === 'object'` constraint in prop lookup
Allows rendering properties of primitive types that are not objects, such as a string.
* pop lookup needs to use hasOwnProperty for non-objs
* re-add constraint in prop lookup, but make property lookups for primitives possible through dot notation
* add test to address #589 specifically
* enhance readability of primitiveHasOwnProperty and add comments to explain why it is used in one case but not the other
Pull requests #643 and #664 together fix the issue reported in issue #617, but the change in behavior is causing semvers concerns. See issue #669. Therefore, roll back #643 and #664 and later reintroduce in next planned major release (v3.0).
Fixes#669
* Fixes CLI tests for windows
* Hijacked exec so we don't have to wrap each command in changeForOS, and made replacing 'cat' safer with word boundaries
* Fixing changed tests to be more consistent with the code base
As we require the template to be a `string` we now throw an error when given
any other data type. This should provide the developers with a meaningful
error rather than a cryptic TypeError from the murky depths of our source code.
Fixes#464
Mejia1994
Phillip Johnsen
Trevor Manz
Sophie Kirschner
Tim Gates
Ricardo Aielo
Andrew Leedham
Eamonn O'Brien-Strain
Yotam Madem
Justin
Enno Woortmann
Kevin Dew
Anders Kaseorg
Raymond Lam
Ashinoko
kookookchoozeus
David da Silva
wizawu
palkan