5 ms·

This is a great illustration why using random babel plugins you find on the internet is super dangerous. This works because it assumes you have named your loca

by Touche 10y ago

This is a great illustration why using random babel plugins you find on the internet is super dangerous. This works because it assumes you have named your local identifier either `markdown` or `md` and are using that. If you want to use something else you need to specify a custom pragma: https://github.com/threepointone/markdown-in-js#pragma https://github.com/threepointone/markdown-in-js#pragma. And that feature didn't exist until 6 hours ago. Why is this dangerous? Let's imagine you use `markdown` and you chug along for another 5 months on this project and you need to use `mdown` in some file, or maybe a coworker uses `mdown` because why not? So it doesn't work. And you're confused. And you spend hours trying to figure out why your app is broke. People need to realize that by using a bunch AST transforms you are creating your own one-off language, and one that has no visual indicator that this is different in any way. It's just a tagged template literal, right? Stick to babel plugins for official language features that at least have a chance of becoming part of JavaScript. This thing is going to stop working as soon as the developer loses interest, and then you're going to be stuck with your Frankenstein language no one can understand.

masterj 10y ago
It's just applying a function to a tagged template literal at compile-time instead of run-time, but it doesn't change the semantics of the language. Calling it a one-off language is hyperbole. Think of it as a compiler optimization step. You bring up a good point with the hard-coded name though. Instead of hardcoding in the pragma it should probably check the name in the require. This wouldn't be difficult to add, and the project is only two days old.
- Touche 10y ago
  It's not a compiler optimization step. Your code will through without the plugin: https://github.com/threepointone/markdown-in-js/blob/master/src/index.js#L3 https://github.com/threepointone/markdown-in-js/blob/master/...
phpnode 10y ago
Here's a PR that fixes this issue - https://github.com/threepointone/markdown-in-js/pull/2 https://github.com/threepointone/markdown-in-js/pull/2
- threepointone 10y ago
  merged and published, thanks!
- Touche 10y ago
  Note that local identifiers (such as vars) mask the import identifier so it will be easy to create a false positive.
  - morgante 10y ago
    It seems like you're looking to find something to complain about. Yes, you generally have to be careful about variable collisions. That is in no way specific to this module and, frankly, is something any competent programmer should be aware of.
    - Touche 10y ago
      It is specific to this project, in that it will rewrite your code to mean something other than what you intended it to mean. I'm not being critical of this project, I'm being critical of the all too common practice these days of installing a dozen or more Babel plugins to fix every problem that exists, and thus creating your own one-off language that will be unreadable in 6 months. Babel has become the new hammer in front-end development. Everything looks like a nail.
      - morgante 10y ago
        I really don't see where you're getting that from. How on earth does it "rewrite your code to mean something other than what you intended it to mean?" I explicitly included the "markdown" identifier. What on earth could I have meant otherwise? How is: import markdown from 'markdown-in-js'; const MyMarkdown = markdown`#Headline`; any less clear than: import markdown from 'markdown-function-tool'; const MyMarkdown = markdown('#Headline'); It's totally explicit and actually allows compile-time validation. I really don't understand your objection. This will not be "unreadable in 6 months" any more than JSX or GraphQL are. Since I have plenty of projects that are over 6 months old using those techniques, I'm quite confident they work fine. It's not like there's any magic or implicit references going on.
deleted 10y ago
[deleted]
kylecordes 10y ago
> creating your own one-off language It seems to me that this is nearly universal among nontrivial front and projects. Each one, through its build configuration, has a slightly different subset of all the language features supported by the current crop of JavaScript derived languages. I believe this is a much underappreciated risk, that some projects will pay a significant price for, a few years from now. We are managing it on our projects by preferring TypeScript, which appears to be advancing forward at a healthy yet careful pace, and which offers some configurability of the exact meaning of the language (in the form of settings in one file), yet does not offer unlimited arbitrary combinations of add-ons. (That said, the Babel ecosystem is amazing, with lots of very interesting work by very smart people.)
- Touche 10y ago
  > It seems to me that this is nearly universal among nontrivial front and projects. Each one, through its build configuration, has a slightly different subset of all the language features supported by the current crop of JavaScript derived languages. It don't know what you mean, but it's certainly avoidable. You can do a few things: * Only use language features of the browsers you are targeting. If you are targeting evergreen browsers (not IE) you can use most of ES2015 including classes, arrow functions, and template literals. * Or use a transpiler but stick to some sane judgment of presets, preferable Stage 3 or greater, but at least stuff that's on the standards track. * Don't use stuff like this: https://www.npmjs.com/package/babel-root-import https://www.npmjs.com/package/babel-root-import that exists only to save yourself a couple of keystrokes.

by Touche 10y ago

masterj 10y ago

It's just applying a function to a tagged template literal at compile-time instead of run-time, but it doesn't change the semantics of the language. Calling it a one-off language is hyperbole. Think of it as a compiler optimization step. You bring up a good point with the hard-coded name though. Instead of hardcoding in the pragma it should probably check the name in the require. This wouldn't be difficult to add, and the project is only two days old.

Touche 10y ago
It's not a compiler optimization step. Your code will through without the plugin: https://github.com/threepointone/markdown-in-js/blob/master/src/index.js#L3 https://github.com/threepointone/markdown-in-js/blob/master/...

phpnode 10y ago

Here's a PR that fixes this issue - https://github.com/threepointone/markdown-in-js/pull/2 https://github.com/threepointone/markdown-in-js/pull/2

threepointone 10y ago
merged and published, thanks!
Touche 10y ago
Note that local identifiers (such as vars) mask the import identifier so it will be easy to create a false positive.
- morgante 10y ago
  It seems like you're looking to find something to complain about. Yes, you generally have to be careful about variable collisions. That is in no way specific to this module and, frankly, is something any competent programmer should be aware of.
  - Touche 10y ago
    It is specific to this project, in that it will rewrite your code to mean something other than what you intended it to mean. I'm not being critical of this project, I'm being critical of the all too common practice these days of installing a dozen or more Babel plugins to fix every problem that exists, and thus creating your own one-off language that will be unreadable in 6 months. Babel has become the new hammer in front-end development. Everything looks like a nail.
    - morgante 10y ago
      I really don't see where you're getting that from. How on earth does it "rewrite your code to mean something other than what you intended it to mean?" I explicitly included the "markdown" identifier. What on earth could I have meant otherwise? How is: import markdown from 'markdown-in-js'; const MyMarkdown = markdown`#Headline`; any less clear than: import markdown from 'markdown-function-tool'; const MyMarkdown = markdown('#Headline'); It's totally explicit and actually allows compile-time validation. I really don't understand your objection. This will not be "unreadable in 6 months" any more than JSX or GraphQL are. Since I have plenty of projects that are over 6 months old using those techniques, I'm quite confident they work fine. It's not like there's any magic or implicit references going on.

deleted 10y ago

[deleted]

kylecordes 10y ago

> creating your own one-off language It seems to me that this is nearly universal among nontrivial front and projects. Each one, through its build configuration, has a slightly different subset of all the language features supported by the current crop of JavaScript derived languages. I believe this is a much underappreciated risk, that some projects will pay a significant price for, a few years from now. We are managing it on our projects by preferring TypeScript, which appears to be advancing forward at a healthy yet careful pace, and which offers some configurability of the exact meaning of the language (in the form of settings in one file), yet does not offer unlimited arbitrary combinations of add-ons. (That said, the Babel ecosystem is amazing, with lots of very interesting work by very smart people.)

Touche 10y ago
> It seems to me that this is nearly universal among nontrivial front and projects. Each one, through its build configuration, has a slightly different subset of all the language features supported by the current crop of JavaScript derived languages. It don't know what you mean, but it's certainly avoidable. You can do a few things: * Only use language features of the browsers you are targeting. If you are targeting evergreen browsers (not IE) you can use most of ES2015 including classes, arrow functions, and template literals. * Or use a transpiler but stick to some sane judgment of presets, preferable Stage 3 or greater, but at least stuff that's on the standards track. * Don't use stuff like this: https://www.npmjs.com/package/babel-root-import https://www.npmjs.com/package/babel-root-import that exists only to save yourself a couple of keystrokes.