v14 upgrade issues

[saptisunil]

I am not able to use these const nlp = require('compromise') nlp.extend(require('compromise-numbers')) in the react app. it shows nlp.extend is not a function. Similarly for emails() also it shows the same. How can we solve that? Thanks in Advance

[spencermountain]

hi Sapti, are you running 13.11.3? you can see an example both extend() and emails() working here https://runkit.com/spencermountain/6111586026f6e1001b4bf8bb cheers

[automotola]

I have this issue with both 13.11.4 & 13.11.3.

[spencermountain]

hi @automotola sorry about this - this part of the api is in-flux, and being addressed properly in our upcoming v14 release. you may be able to use .plugin() instead of .extend() - they are aliases of the same thing. let me know if this does not work cheers

[automotola]

@spencermountain I didn't get it to work yet on those versions.

[spencermountain]

you can see extend working in the documentation here the front-end demo here or the many tests here cheers

[jfemia]

Hi, please can you clarify what is the correct way to do this in 14.1?

Docs still say .extend, but it doesn't seem to exist (or maybe it does and is missing from TS typings? - it doesn't complain if I //@ts-ignore it.) Is .plugin now the way to go? I'm trying to update an older project from 13.1 to 14.1, and I can't seem to get it to play nicely with compromise-numbers - I was previously using .extend and I tried using .plugin instead but regardless which I use, if I then try and call something like units() it's not a function:

...
import numbers from 'compromise-numbers';
nlp.plugin(numbers)
const test = nlp("5 kg")
test.numbers().units() // units is not a function

Thanks

[evenfrost]

Stumbled upon this as well while upgrading to v14. A migration guide with old -> new examples would be great to have.

[evenfrost]

I just found out that v14 has switched to ES Modules, which in my case makes it impossible to use on an existing TypeScript Node.js project. So I'm just sticking to v13 for the time being.

It's up to project author to choose the direction of development for sure, though I think it would be good to outline this transition in the changelog, because this is a pretty drastic one.

FWIW, Here are some common issues people are facing when migrating to ES Modules.

[spencermountain]

hey - yeah v14 is a big one. and moving to modules is a small pain too. sorry for the confusions.

.extend() and .plugin() are just aliases. I'll add extend() to the types. thanks for catching that.

@jfemia numbers-plugin is included is included by default in v14. You won't need to import it anymore.

@evenfrost i've heard about this typescript esmodule stuff, which sound like a nightmare. is there anything I can do on my end? cheers

[evenfrost]

No worries and no actions are needed from your end, thanks for the response.

I think it should be okay to use v14 in a new TS Node.js project if one chooses to use ESM on the server side from the very start. As for existing projects, especially big ones, I believe we have to just wait and see where it goes. There is already some tooling that should help with migration but from what I saw it's still in its early days.

[jfemia]

@spencermountain thanks for the response - I've removed my imports for the numbers plugin, although I'm still hitting the problem with units() is not defined.

const test = nlp("5 kg")
test.numbers().units(); // units not a function

Has the usage of this changed? I noted while reading the readme that the numbers() section does not have a units() method - has it been removed and if so is there an alternative way (in this case for it to give me the "kg" part of that test string)?

I used to use it as described in these docs: https://observablehq.com/@spencermountain/compromise-values

[spencermountain]

hey Jamie, sorry yeah .units() has been pulled-back, you can now do numbers().json() to get them:

nlp('2km by foot').numbers().json()
//[{... number:{suffix:'km'}}]

I'd love to know how you're using the unit parser. It's always felt really goofy for me.

... should 'three wishes' return 'wishes' as a unit? 5 km should return a compromise view of the 'km' term, so it can be mutated and stuff, but 5km can only return a bare string. There was a time when .numbers() would include the unit, which messed up the number-parser.

I've removed it from the docs, but would love to bring it back, somehow. Separated terms are still tagged with #Unit, so for now, you can use doc.numbers().growRight('#Unit') to support '5 km' phrases like this cheers

[jfemia]

For context on units(), I'm parsing food recipe ingredients - "2 kg potatoes", etc - in this instance I am looking for measurements immediately following a number, and then extracting the number and unit as separate values.

In fact, I was only using units() to get a view on unit strings immediately following the number itself - I was then matching them against my own list of cooking related measurement words in a plugin that tagged them with #RecipeUnit (because things like kilometres of cheese are not normal recipe ingredients...)

Looks like I can use growRight('#RecipeUnit').match('#RecipeUnit') to give me a view containing only the unit string, which is what I'm after. I looked for some other methods to avoid redundancy (matching the tag twice), but I couldn't find anything else that would "look at exactly the next word and match it with a tag" - after goes further in the string and might hit false positives. Anyway, my unit related unit tests are passing now so thanks for that!

Next set of failures for me (sorry!) is that the normalize step with {plurals: false} doesn't actually seem to de-pluralise all the words. (Not 100% sure if false means "do something" or not in this case but it doesn't change when true either)

One test case of mine is the string "2 kg Maris Piper potatoes", which after normalize used to contain "potato" but is now leaving "potatoes" untouched. Also "a few stalks celery" used to become "a few stalk celery" but now remains untouched.

For reference the whole set of normalize params is

{
      whitespace: true,
      case: true,
      punctuation: false,
      unicode: true,
      contractions: false,
      acronyms: false,
      plurals: false
}

and looking at doc.json() before and after does show it's done things like case and punctuation successfully.

Reproducer here https://runkit.com/jfemia/628d3066ffd91e0009c35ded

[spencermountain]

hey @jfemia i think it's {nouns:true} now - hah, and yeah, for exactly the reason you mentioned.

Params have been updated here, cheers

[jfemia]

Hmm, it seems to get confused by the extra words in the text - when it only contains potatoes it works, but not with Maris Piper potatoes https://runkit.com/jfemia/628d3066ffd91e0009c35ded