feat: add support for vue-i18n custom blocks by default #227

JessicaSachs · 2020-03-10T22:57:20Z

This PR adds support for an extensible API to parse and process custom blocks.

See the rendered README for API changes and writing a processor

// jest.config.js
module.exports = {
  // ...
  globals: {
    'vue-jest': {
      transform: {
        'your-custom-block': './your-transformer.js'
      }
    }
  }
}

kazupon · 2020-03-11T02:56:52Z

@JessicaSachs
Thank you for your support !

I'm glad you support i18n custom blocks by default in vue-jest.
However, if we will consider the maintainability of vue-jest, I think that it's should provide an interface that supports transform to code for custom blocks.

vue-jest seem that have already a mechanism that user can transform to code.
You can see the code in processStyle of lib/process-style.js.

https://github.com/vuejs/vue-jest/blob/master/lib/process-style.js#L67-L93

In the above, the custom transformer path gets from the jest config and require it, and the code is generated by custom transformer.

As well as, I think we can do custom blocks.
The custom transformer need to provide with library author like vue-i18n, but I don't think it's a problem because it's the responsibility of side providing custom blocks.

JessicaSachs · 2020-03-11T02:58:25Z

I agree! In discord I am asking for help to design an extensible interface for custom blocks :-) come chat with me.

…

On Tue, Mar 10, 2020 at 10:57 PM kazuya kawaguchi ***@***.***> wrote: @JessicaSachs <https://github.com/JessicaSachs> Thank you for your support ! I'm glad you support i18n custom blocks by default in vue-jest. However, if we will consider the maintainability of vue-jest, I think that it's should provide an interface that supports transform to code for custom blocks. vue-jest seem that have already a mechanism that user can transform to code. You can see the code in processStyle of lib/process-style.js. https://github.com/vuejs/vue-jest/blob/master/lib/process-style.js#L67-L93 In the above, the custom transformer path gets from the jest config and require it, and the code is generated by custom transformer. As well as, I think we can do custom blocks. The custom transformer need to provide with library author like vue-i18n, but I don't think it's a problem because it's the responsibility of side providing custom blocks. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#227?email_source=notifications&email_token=AAVL4BFW7VUPH4AW5KVJLD3RG34YJA5CNFSM4LFJRW5KYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEON6GEI#issuecomment-597418769>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVL4BGEP5IO4L2QJ4CLSLLRG34YJANCNFSM4LFJRW5A> .

JessicaSachs · 2020-03-18T22:04:34Z

OK! @kazupon, @lmiller1990, @afontcu, and @dobromir-hristov would love feedback from any and all of you 🙇‍♀

lmiller1990

I think the code looks fine, mostly questions rather than real feedback!

lmiller1990 · 2020-03-18T23:19:36Z

lib/transformers/i18n.js

+    return JSON.stringify(JSON.parse(convert(content, langKnown)))
+  }
+
+  try {


do we need a warning here? "Your file is not valid JSON or YAML".

Could do. I matched the existing code.

lmiller1990 · 2020-03-18T23:20:04Z

lib/transformers/i18n.js

+    const codes = blocks.map(block => {
+      if (block.type === 'i18n') {
+        const value = parseLanguageAndContent(block, filename)
+          .replace(/\u2028/g, '\\u2028')


What do these codes represent?

They're line seperators, but really, I have no idea, I copied them from vue-i18n-jest

ok, vue-i18n is battle tested, going to assume kazupon knows what he is doing

lmiller1990 · 2020-03-18T23:21:43Z

lib/process-custom-blocks.js

+const { getVueJestConfig, getCustomTransformer } = require('./utils')
+const vueOptionsNamespace = require('./constants').vueOptionsNamespace
+
+function applyTransformer(


Should we try to match the jest process api a bit more closer? That would be `applyTransform(blocks, filename, config, transformer, vueOptionsNamespace) I guess. Although maybe more awkard to call then - just thinking out loud

I wasn't sure about this either. I think if there was no external context, like if jest process didn't exist, maybe an object-based api would be best, because there's a lot of optional params.

Object based works well for me too - what do you think? I really like to use an object when there are more than 1-2 params, since it is easier to read.

If it's not too much trouble that change could go with that? I don't mind too much, though.

Updating it for this

lmiller1990 · 2020-03-18T23:23:15Z

lib/generate-code.js

@@ -21,7 +24,7 @@ module.exports = function generateCode(
  }

  output +=
-    `var __options__ = typeof exports.default === 'function' ` +
+    `var ${namespace} = typeof exports.default === 'function' ` +


Any specific reason to move the constant to another file? It seems to be used elsewhere when it wasn't before - why is that?

Because it was being hardcoded inside of vue-i18n-jest and Edd refactored this in v4, which broke vue-i18n-jest if we were to have released v4 of vue-jest... We should make any required constants passed in rather than requiring developers to dig into vue-jest source code to figure out what constants we're using when they're writing their processors

Right, makes sense, sounds good

kazupon · 2020-03-19T11:17:07Z

@JessicaSachs
Thanks a lot!.

I'm realy gload to support vue-i18n as default at vue-jest.
But the supporting at least one custom block will seem unfair to the creator of the library that provides the custom block.

I hope that vue-jest will offer I/F only for custome blocks without natively supporting vue-i18n. :)

JessicaSachs · 2020-03-19T14:57:59Z

No problem. I’m happy to remove the processor natively now that we’re supporting custom blocks generally.

…

On Thu, Mar 19, 2020 at 7:17 AM kazuya kawaguchi ***@***.***> wrote: @JessicaSachs <https://github.com/JessicaSachs> Thanks a lot!. I'm realy gload to support vue-i18n as default at vue-jest. But the supporting at least one custom block will seem unfair to the creator of the library that provides the custom block. I hope that vue-jest will offer I/F only for custome blocks without natively supporting vue-i18n. :) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#227 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAVL4BB7NPGGSOGZVOPMLCTRIH5MHANCNFSM4LFJRW5A> .

JessicaSachs · 2020-03-19T19:06:35Z

@kazupon Here is the file tree with the final implementation of vue-i18n natively. As discussed, I removed it from this PR.

Please feel free to adapt this into your own package. I made some improvements on the existing wrapper you built, so please take a look 🙇‍♀

kazupon · 2020-03-20T15:23:29Z

@JessicaSachs
Okay! Thanks!

ghost · 2020-03-22T15:34:09Z

package.json

@@ -72,7 +73,8 @@
    "chalk": "^2.1.0",
    "convert-source-map": "^1.6.0",
    "extract-from-css": "^0.4.4",
-    "source-map": "^0.5.6",


@JessicaSachs this package is used here

vue-jest/lib/generate-source-map.js

Line 2 in 0b0d5e2

const sourceMap = require('source-map')

JessicaSachs force-pushed the feat/support-custom-i18n-blocks-natively branch 2 times, most recently from da97129 to 3013e13 Compare March 10, 2020 23:08

JessicaSachs mentioned this pull request Mar 10, 2020

Add support of custom block like the i18n #116

Closed

JessicaSachs force-pushed the feat/support-custom-i18n-blocks-natively branch from 3013e13 to 832450e Compare March 10, 2020 23:18

JessicaSachs requested review from kazupon and lmiller1990 March 10, 2020 23:21

JessicaSachs force-pushed the feat/support-custom-i18n-blocks-natively branch from 832450e to c49525e Compare March 10, 2020 23:23

JessicaSachs added 2 commits March 18, 2020 04:36

feat: add support for vue-i18n custom blocks by default

1ec8978

feat: add support for custom blocks inside of the vue-jest global config

7a2e92a

JessicaSachs force-pushed the feat/support-custom-i18n-blocks-natively branch from 1dc4982 to 7a2e92a Compare March 18, 2020 08:36

lmiller1990 approved these changes Mar 18, 2020

View reviewed changes

docs: document the custom block processor feature

df2bfa2

JessicaSachs force-pushed the feat/support-custom-i18n-blocks-natively branch from d53e699 to df2bfa2 Compare March 19, 2020 02:20

JessicaSachs force-pushed the feat/support-custom-i18n-blocks-natively branch from 1684495 to 2f4901a Compare March 19, 2020 18:09

feat: support custom blocks without i18n natively

a71a99b

JessicaSachs force-pushed the feat/support-custom-i18n-blocks-natively branch from 2f4901a to a71a99b Compare March 19, 2020 18:11

JessicaSachs merged commit d6c4e47 into master Mar 19, 2020

ghost reviewed Mar 22, 2020

View reviewed changes

nogic1008 mentioned this pull request Mar 23, 2020

Use <i18n> custom block on Vue Single File Component nogic1008/nuxt-ts-template#69

Closed

lmiller1990 deleted the feat/support-custom-i18n-blocks-natively branch March 23, 2020 07:09

kazupon mentioned this pull request Sep 1, 2020

[feature request] add built-in <i18n> block processor for vue-jest kazupon/vue-i18n#984

Closed

feat: add support for vue-i18n custom blocks by default #227

feat: add support for vue-i18n custom blocks by default #227

Uh oh!

Conversation

JessicaSachs commented Mar 10, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kazupon commented Mar 11, 2020

Uh oh!

JessicaSachs commented Mar 11, 2020 via email

Uh oh!

JessicaSachs commented Mar 18, 2020

Uh oh!

lmiller1990 left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

JessicaSachs Mar 18, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

kazupon commented Mar 19, 2020

Uh oh!

JessicaSachs commented Mar 19, 2020 via email

Uh oh!

JessicaSachs commented Mar 19, 2020 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

kazupon commented Mar 20, 2020

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

JessicaSachs commented Mar 10, 2020 •

edited

Loading

JessicaSachs Mar 18, 2020 •

edited

Loading

JessicaSachs commented Mar 19, 2020 •

edited

Loading