zspecza / common-tags Goto Github PK

Version 6.24.0 of babel-register just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As babel-register is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

It's possible to use a template tag as a transformer by latching on to it's transformers property so we can effectively do this:

import {TemplateTag, stripIndent} from 'common-tags'

const upcaseTransformer = () => ({
  onEndResult (endResult) {
    return endResult.toUpperCase()
  }
})

// focus less on the implementation, more on how we're passing `stripIndent` as if it were
// a transformer plugin
const upcase = new TemplateTag(stripIndent, upcaseTransformer)

Version 2.3.11 of micromatch just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As micromatch is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

https://github.com/declandewet/common-tags#commalistsand

^ shows the output
I like apples, bananas, and watermelons

Actual output
I like apples, bananas and watermelons

I'm not sure which you're intending to be the correct behavior.

Related:
If you do support Oxford comma, then you need to support:

"Foo and bar"
The current inline transformer with separator and conjunction options looks like it would only handle:
"Foo, and bar" with a comma.

Test case:

const stripIndent = require('common-tags').stripIndent;

const line1 = stripIndent`
    line1.0
    line1.1`;

console.log(line1);

const line2 = stripIndent`
    ${line1}
    line2.0`;

console.log(line2);

Output:

line1.0
line1.1
line1.0
line1.1
    line2.0

As you see, line2.0 isn't de-indented. I'm not sure if it's expected behaviour. If so, how can I achieve desired effect? Thanks for nice lib!

Version 3.7.8 of when just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As when is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version 6.15.0 of babel-plugin-transform-runtime just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As babel-plugin-transform-runtime is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Arrays are nicely indented:

html`
    <ul>
        ${['foo', 'bar'].map(x => `<li>${x}</li>`)}
    </ul>
    `

The output is:

<ul>
    <li>foo</li>
    <li>bar</li>
</ul>

Occasionally, one may insert chunks of text, not Arrays. Then it’d be great to have the option of indenting text after line breaks. In other words, the following code should produce the same output as the previous code:

html`
    <ul>
        ${'<li>foo</li>\n<li>bar</li>'}
    </ul>
    `

stripIndents now replaces multiple newlines with a single one.

console.log(stripIndents`
a
b

c
`);

1.4.0 output:

a
b

c

1.5.0 output:

a
b
c

I came across this library via 2ality. Thanks for this great collection of problem solvers!

My main use is for the html tag - but my template contains JavaScript source code, not HTML. In fact the html tag is pretty useful while generating any block-structured code with correct indenting.

It looks a little strange and not so self-documenting to see JavaScript source inside a html tagged template. At present I just import it using something like import {html as js} from 'common-tags', but it also looks a bit odd seeing html there.

So, I was wondering if this tag could have a more generic name (or at least an alias) exported from the library itself?

More information: https://github.com/rollup/rollup/wiki/jsnext:main

And then anyone doing a normal Node.js require, say in 4.x, would no longer be forced into loading babel-runtime into their production processes.

I was just about to recommend this library to my network, but that runtime dependency is a deal-breaker.

Really, I'd recommend that you babel down to lowest common denominator (ES5) to make it easier for users to webpack their components. The standard webpack/babel configuration excludes node_modules: https://github.com/babel/babel-loader#usage

Version 0.10.2 of regenerator-runtime just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As regenerator-runtime is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

I just noticed in a stylelint/stylelint Travis CI job the warning:

npm WARN engine [email protected]: wanted: {"node":">=4.0.0","npm":">=3.0.0"} (current: {"node":"4.4.7","npm":"2.15.8"})

In your readme requirements: https://github.com/declandewet/common-tags#requirements 👍

"NPM (v3.0.0+ highly recommended) (this comes with Node.js)"

When NodeJS 4.x is installed with NVM as Travis CI does it does not install the latest NPM 3.x.x branch, the 2.x.x branch is used, you can also see this in your own 4.x Travis job:
• https://travis-ci.org/declandewet/common-tags/jobs/139596870#L123

2.28s$ nvm install 4
Downloading https://nodejs.org/dist/v4.4.5/node-v4.4.5-linux-x64.tar.xz...
######################################################################## 100.0%
Now using node v4.4.5 (npm v2.15.5)
...
$ node --version
v4.4.5
$ npm --version
2.15.5
$ nvm --version
0.31.0
install
8.15s$ npm install 

The NodeJS 5.x branch doesn't have this issue as it uses NPM 3.x for example:
• https://travis-ci.org/declandewet/common-tags/jobs/139596869#L123

NodeJS 4.x.x is the LTS (Long Term Support) NodeJS release: https://github.com/nodejs/LTS/blob/master/README.md

NPM 2.x.x is the LTS NPM release: https://github.com/npm/npm/wiki/Roadmap#tactical-roadmap

So, does common-tags really require NPM 3.x.x? Would you consider removing the 3.x.x requirement? It appears to work fine with common-tags and stylelint using NPM 2.x.x

Occasionally, it’d be nice if one could dedent the output of another tag function, like this:

stripIndent(String.raw)`
    abcdefg
`;

That could be achieved by making all functions behave differently if the first (and only) parameter is a function.

Version 6.24.1 of babel-preset-stage-0 just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As babel-preset-stage-0 is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

If I have a top level block of code that looks like this:

const myString = oneLineTrim`
hello
world
`

This will not properly combine the lines into a single line.
If you look at the regex for oneLineTrim, it appears to need at least one space after the newline:

replaceResultTransformer(/(?:\n\s+)/g, '')

When I'm including data that was serialized using node's util.inspect function, stripIndent seems to be making some mistakes on how to handle the indent stripping. Here's the script and the output as an example:

'use strict';
const commonTags = require('common-tags');
const util = require('util');


const obj = {
	prop1: 'asdfasdfasdfsadfasdf asdfasdfasdfsadfasdf',
	prop2: 'asdfasdfasdfsadfasdf asdfasdfasdfsadfasdf',
	shape: {
		prop3: 'asdfasdfasdfsadfasdf asdfasdfasdfsadfasdf',
		prop4: 'asdfasdfasdfsadfasdf asdfasdfasdfsadfasdf'
	}
}

if (true) {
	if (true) {
		console.log(commonTags.stripIndent`
			Some firstline message
			Some secondline message
			${util.inspect(obj)}
		`);
	}
}

Actual output:

Some firstline message
        Some secondline message
        { prop1: 'asdfasdfasdfsadfasdf asdfasdfasdfsadfasdf',
prop2: 'asdfasdfasdfsadfasdf asdfasdfasdfsadfasdf',
shape:
 { prop3: 'asdfasdfasdfsadfasdf asdfasdfasdfsadfasdf',
   prop4: 'asdfasdfasdfsadfasdf asdfasdfasdfsadfasdf' } }
vagrant@dev:/opt/signal (alert-check-update)$ node scratch/data-test.js

Expected output:

Some firstline message
Some secondline message
{ prop1: 'asdfasdfasdfsadfasdf asdfasdfasdfsadfasdf',
  prop2: 'asdfasdfasdfsadfasdf asdfasdfasdfsadfasdf',
  shape:
   { prop3: 'asdfasdfasdfsadfasdf asdfasdfasdfsadfasdf',
     prop4: 'asdfasdfasdfsadfasdf asdfasdfasdfsadfasdf' } }

Awesome project here! I had just finished reworking a bunch of examples for Netlify CMS using stripIndent when I realized there's no way to "just use it" via a CDN like unpkg.com. Have you considered providing built files?

Version 6.24.0 of babel-preset-latest just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As babel-preset-latest is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Being able to chain an infinite amount of tags would be really useful.

It would basically be the same functionality as the tail processing syntax:

tag(otherTag)`some text`

but instead of being limited to one extra tag, you could chain as many as you want

tag.otherTag.thirdTag`some text`

Currently, the html tag produces invalid markup when a null value is encountered:

import {html} from 'common-tags'

const todos = [{
  task: 'some task',
  done: false
}, {
  task: 'other task',
  done: true
}]

html`
  <h1>Incomplete tasks:</h1>
  <ul>
    ${todos.map((t) => t.done ? null : `<li>${t.task}</li>`)}
  </ul>
`

Produces:

<h1>Incomplete tasks</h1>
<ul>
  <li>some task</li>
  null
</ul>

This causes errors when trying to use it.

Version 7.1.1 of babel-eslint just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As babel-eslint is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version 6.22.0 of babel-cli just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As babel-cli is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

I think there's some kind of issue with interpolation/substitution with the source tag - for instance, if I do something like

const baz = "baz\nquux\ngarply";
source`
  Foo
  Bar

  ${baz}
`

where baz contains newlines, the result will have all the newlines within baz doubled:

Foo
Bar

baz

quux

garply

but I would have expected

Foo
Bar

baz
quux
garply

This only happens if the interpolation is preceded by a newline.

Interestingly, if I do something like

source`${baz}`

the newlines actually get turned into spaces, which is also not what I would have expected.

I think it has something to do with the fact that source blocks attempt to match the outer indentation level when you interpolate a variable? I.e.,

source`
  Foo:
    Bar
    ${baz}
`

becomes

Foo:
  Bar
  baz
  quux
  garply

Version 1.2.13 of which just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As which is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version 2.6.0 of rimraf just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As rimraf is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version 1.2.12 of which just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As which is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

I feel a little bad posting this here, I'm not 100% convinced that common-tags is the problem, but it's the top of the stack trace, so here goes...

Occasionally our webpack build will start giving the following error:

 ERROR in ./node_modules/common-tags/lib/oneLine/index.js
    Module build failed: Error: /Users/joe/Code/lendinghome-treefuls/feature-1/node_modules/common-tags/lib/oneLine/index.js: original.line and original.column are not numbers -- you probably meant to omit the original mapping entirely and only map the generated position. If so, pass null for the original mapping instead of an object with empty or null values.
        at SourceMapGenerator_validateMapping [as _validateMapping] (/Users/joe/Code/lendinghome-treefuls/feature-1/client/src/monopack/node_modules/source-map/lib/source-map-generator.js:276:15)
        at SourceMapGenerator_addMapping [as addMapping] (/Users/joe/Code/lendinghome-treefuls/feature-1/client/src/monopack/node_modules/source-map/lib/source-map-generator.js:110:12)
        at /Users/joe/Code/lendinghome-treefuls/feature-1/client/src/monopack/node_modules/babel-core/lib/transformation/file/index.js:467:27

It happens with or without, hot module reload enabled and in between builds without ANY changes to node modules. The only solution is to remove all node_modules folders and try again. This happens at least three or four times a day to multiple devs on our team.

The only reason I'm suspicious of this library is because if I remove all uses of the oneLine tag, everything works again. Once I revert that change, it breaks immediately. I've googled it, and it seems like lot's of people run into this error with various libs (see mozilla/source-map#304, webpack/webpack-sources#28 and webpack/webpack#6131). We do not use the libraries listed in these issues.

I don't have the time right now, but I'll try to see if I can reproduce this in a separate repo. I'm posting this right now to gather data and see if anyone has this issue with common-tags in the stack trace. Or maybe if the maintainers here have any thoughts on whether or not this library is the root cause.

Thanks!

EDIT: Thought I'd add that our app is being transpiled with babel-runtime 6.26.0, and regerator-runtime 0.11.0. We are currently on common-tags 1.4.0, but I still saw this same issue after updating to the latest. Also, our webpack build has multiple entry points, not all of which use common-tags. If I remove the ones that DO use it, the build succeeds. As soon as I put them back, it fails again with the same error.

I really like using this pkg, and I really need sometimes to use the same great functions for strings,
currently I do oneLine([someString])

Can you please add support for strings so we could do oneLine(someString)?
Thanks

Version 6.20.0 of babel-runtime just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As babel-runtime is a direct dependency of this project this is very likely breaking your project right now. If other packages depend on you it’s very likely also breaking them.
I recommend you give this issue a very high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Its name and test suggest that it would ("reduces text to one line, replacing newlines with spaces").

For example the following is unexpected

oneLine`
  Preserve eg sentences.  Double
  spaces within input lines.
` === 'Preserve eg sentences.  Double spaces within input lines.'
// => false

It’d be nice to have the option to escape inserted content (you’d only need to detect a prefixed dollar sign):

const name = '<Jane>';
console.log(html`Name: $${name}`);
    // Name: &lt;Jane&gt;

The function that escapes could be configurable. One simple implementation:

function htmlEscape(str) {
    return str.replace(/&/g, '&') // first!
              .replace(/>/g, '>')
              .replace(/</g, '&lt;')
              .replace(/"/g, '&quot;')
              .replace(/'/g, '&#39;')
              .replace(/`/g, '&#96;');
}

Is there any way to use your library without pulling babel? Kinda wierd.

Version 1.2.0 of doctoc just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As doctoc is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

Version 6.23.0 of babel-plugin-transform-runtime just got published.

This version is covered by your current version range and after updating it in your project the build failed.

As babel-plugin-transform-runtime is “only” a devDependency of this project it might not break production or downstream projects, but “only” your build or test tools – preventing new deploys or publishes.

I recommend you give this issue a high priority. I’m sure you can resolve this 💪

Your Greenkeeper Bot 🌴

The library uses a few newer ES features - one of which is the String.prototype.includes method (related: #112). It would be nice to document them, so that it's easier to polyfill them if needed.

Also might be related: #103.

The side variable needs to be scoped more specifically. On a second iteration, it is capitalized, breaking the 'left' || 'right' check

When converting objects into strings that have a custom toString method, I've noticed the lib calls valueOf instead. I don't know if this is intentional, but it really is confusing if you aren't expecting this behavior.

console.log(stripIndents`
    ${obj} is cool!
`);

Assuming obj has a valueOf that returns "1" and a toString that returns "2", the valueOf gets called, which in normal template literals is not the case.

When includeArrays is used & an array expression has a non-whitespace character preceding it, an error is thrown. Example:

import { commaLists } from 'common-tags';

let templ, myArray = [ 'a', 'b', 'c' ];

// Does not work
templ = commaLists`
    (${myArray})
`;

// Add a space before the expression & suddenly it works.
templ = commaLists`
    ( ${myArray})
`;

I believe it's reasonable to expect to be able to produce output like (a, b, c).

The error is Cannot read property '1' of null, stemming from this line in tags.js:

expression = expression.join(sep + accumulator.match(/(\s+)$/)[1])

If there's no whitespace at the end of accumulator to copy, perhaps it could default to using a single space.

Here is my current code:

function generateFruits () {
  const fruits = [
    {
      name: 'apples',
      quantity: 3
    },
    {
      name: 'oranges',
      quantity: 2
    }
  ]

  return source`
    Fruits
      ${fruits.map(f => `${f.name}: ${f.quantity}`)}
  `
}

If I do console.log(generateFruits()), I get the expected output:

Fruits
  apples: 3
  oranges: 2

However, if I create a variable called template and use generateFruits() inside of there, it doesn't seem to work:

const template = stripIndent`
  ${generateFruits()}
`

I thought that this would give the same output, but instead it seems to give this:

Fruits
apples: 3
oranges: 2

And if I remove the stripIndent, it gives this:

  Fruits
  apples: 3
  oranges: 2

Why does using generateFruits() inside a different template literal make it lose the indentation?

let expectedOutput = stripIndent`
            .foo {
              color: red; }

            .foo {
              color: yellow; }

            .foo {
              color: green; }

            `

Output:

      .foo {\n  color: red; }\n\n.foo {\n  color: yellow; }\n\n.foo {\n  color: green; }

Expected Output:

      .foo {\n  color: red; }\n\n.foo {\n  color: yellow; }\n\n.foo {\n  color: green; }\n

My current workaround:

let expectedOutput = stripIndent`
            .foo {
              color: red; }

            .foo {
              color: yellow; }

            .foo {
              color: green; }
            replace
            `
expectedOutput = expectedOutput.replace('replace', '')

Let me start by saying this project looks awesome.

I need to replace a string inside a javascript file before sending it from a server.

var file = 'var test = ${var}' // or fs.createReadStream('my.js', 'utf8')

reply
      .header('Content-Type', 'application/javascript; charset=UTF-8')
      // replace placeholder in js file
      .send(file)

Would this be possible with this package? 😄

Thanks!

Given the following code

import { oneLineCommaListsAnd } from 'common-tags'
console.log(oneLineCommaListsAnd`${['foo']}`)

I would expect the output to be foo, but the ourput is acutally andfoo.

I've been learning about tagged templates and I discovered common-tags. It's so useful -- many thanks for it!

I was hoping that html might be able to handle nested, multi-line sections, such as you might produce with another html tagged literal. Then you could compose html and have the indenting magically work. But that doesn't seem to be the case.

Here's a test case. Would supporting something like this be at all feasible?

const { html } = require("common-tags");

test("renders nested HTML", () => {
  const fruits = ["apple", "banana", "kiwi"];
  const expected = `<!DOCTYPE html>
<html lang="en">
  <body>
    <ul>
      <li>
        <div>apple</div>
      </li>
      <li>
        <div>banana</div>
      </li>
      <li>
        <div>kiwi</div>
      </li>
    </ul>
  </body
</html>`;

  function renderFruit(fruit) {
    return html`
      <li>
        <div>${fruit}</div>
      </li>`;
  }

  const actual = html`
    <!DOCTYPE html>
    <html lang="en">
      <body>
        <ul>
          ${fruits.map(renderFruit)}
        </ul>
      </body>
    </html>`;

  expect(actual).toBe(expected);
});

There was a new feature: smart trimming declandewet/common-tags@b02295b, but the package hasn't been updated. Could you please land it?

I'm using PhantomJS 1.9.8 to test my browserify build (partly because it's still the travis CI default and partly to make sure I'm not pulling in anything that'll blow up on older browsers) and common-tags does. I checked the repo and since it's building with babel I hoped that'd be "good enough" but it's apparently not. Any gut reaction to this issue before I pull things down and dig in further?