rategravity / parse-full-name Goto Github PK

We came upon this issue today:

var parseFullName = require('parse-full-name').parseFullName;
 
var name = parseFullName('PAYMENTSRDT (ROYAL DEVON AND EXETER NHS FOUNDATION TRUST)','all',1,0,0)

This will error in:

TypeError: Cannot read property 'slice' of undefined

I'll just leave this here for now, until I can make a pull request to include the Typescript definitions.

declare module "parse-full-name" {
    export type PartToReturnSingle = "title" | "first" | "middle" | "last" | "nick" | "suffix" | "error";
    export type PartToReturnAll = "all" | undefined | null;
    export type FixCase = -1 | 0 | 1;

    export interface FullNameParsed {
        title: string;
        first: string;
        middle: string;
        last: string;
        nick: string;
        suffix: string;
        error: string[];
    }

    export function parseFullName(nameToParse: string, partToReturn: PartToReturnSingle, fixCase?: FixCase, stopOnError?: boolean, useLongLists?: boolean): string;
    export function parseFullName(nameToParse: string, partToReturn?: PartToReturnAll, fixCase?: FixCase, stopOnError?: boolean, useLongLists?: boolean): FullNameParsed;
    export function parseFullName(nameToParse: string, partToReturn?: PartToReturnAll | PartToReturnSingle, fixCase?: FixCase, stopOnError?: boolean, useLongLists?: boolean): string | FullNameParsed;
}

I'm not sure if you consider this out-of-scope for this library, but often people have their company name with their own name.

Some examples: T. J. Watson, IBM Corp., T. J. Watson, CEO, IBM Corp..
There are other more "wordy" variations as well: T. J. Watson of IBM Corp., T. J. Watson from IBM Corp..

What are your thoughts on whether these are things you want this library to handle?
Thanks!

a name such as Ezekiel Johnson would be fine as is and returns
{ title: '', first: 'Ezekiel', middle: '', last: 'Johnson', nick: '', suffix: '', error: [] }

but Ezekiel Johnson with a blank space at the end results in

{ title: '', first: 'Ezekiel', middle: 'Johnson', last: '', nick: '', suffix: '', error: [] }

To fix temporarily you can just do nameStr.trim() before you put it into the function

.replace(/\s\s+/g, ' ').trim()

'van den' is treated like a middle name, unlike 'van der', 'van de', etc.

parse('Johannes van den Bosch').last // 'Bosch'
parse('Johannes van der Bosch').last // 'van der Bosch'
parse('Johannes van de Bosch').last  // 'van de Bosch'

While names like this get parsed correctly: Orin Scrivello, DDS (DDS is a suffix)
If you remove the comma (Orin Scrivello DDS) DDS gets treated as a last name.
Alternatively, if you replace the comma with a dash (Orin Scrivello - DDS) - DDS becomes a middle name.

The same issue occurs with multiple titles as well:
Kevin Mitnick, CISSP, CISM vs Kevin Mitnick CISSP, CISM

If there are multiple leading name parts with mixed case, would it make sense to treat one or more caps-only end-parts as suffixes regardless of the comma?

In addition, there are likely some common ones in mixed case that should always be treated as suffixes: PhD, BSc

I'm curious if we can opt-out of the title list or use a custom title list?

Currently, there are valid last names that are parsed as titles.

Example (via RunKit)

Name: John Judge

Result

Desired Result

I'd like to parse Judge in this example as a last name.

For example, "H. Jon Benjamin" or "J. Kenji Lopez-Alt". Should first be "Jon" and "Kenji" respectively? Should there be a separate field?

Running into this error when trying to build storybook with this package as a dependency. Some research indicates that this is a webpack issue and .mjs should be removed from this packages output:
http://github.com/developit/microbundle/issues/426

It might be handy to pass a second optional parameter locale to the parse method. In some cases it is not possible to differ if the order is 'first name lastname' (western countries) or 'lastname firstname' like in some Asian countries. The caller might have some knowledge of the name's locale like en_US or th_TH. This hint might help solving some ambiguities, not only for the given example.

Hi,

I can see that in 7c5ada9 you've added a list of gender-neutral titles to the library, but the version on NPM doesn't appear to include those. Is there a way to reference the master version from GitHub, or could the NPM version be updated to include these?

Thanks! This is such a helpful library 😁

A common German firstname is "Karl-Heinz" or generally a firstname often consists of two parts connected with a hyphen. For some reason the second part is not capitalized.

Noticing something similar with hyphenated last names as well

> parseFullName.parseFullName('ALEXANDRIA OCASIO-CORTEZ')
{ title: '',
  first: 'Alexandria',
  middle: '',
  last: 'Ocasio-cortez',
  nick: '',
  suffix: '',
  error: [] }

Expected:

{ title: '',
  first: 'Alexandria',
  middle: '',
  last: 'Ocasio-Cortez',
  nick: '',
  suffix: '',
  error: [] }

The titleList has a few duplicated values, like mr, ms, dr...

Is this a mistake or it is expected ?

When a full name containing the middle initial "E" or "Y" is inputted into this module, the result is that the first, middle, and last name tokens are interpreted together as the last name.

Examples

input -> "Jimmie E French"
output -> {"title":"","first":"","middle":"","last":"Jimmie E French","nick":"","suffix":"","error":[]}

input -> "Brent Y Hickok II"
output -> {"title":"","first":"","middle":"","last":"Brent Y Hickok","nick":"","suffix":"II","error":[]}

I am also encountering this issue.
I've resorted to a regex replacement to hack around it. Basically, if you put a period after the initial, the parser will understand it as an initial.

var name = "Jimmie E French";
name = name.replace(/\s([A-Z])\s/, ' $1. '); //Converts to Jimmie E. French
var parsedName = parse-full-name( name );

Confirmed seeing this issue.
Thanks for the tip

> parseFullName('Hernandez Rivera, Esperanza')
{
  title: '',
  first: 'Hernadez',
  middle: '',
  last: 'Rivera',
  nick: '',
  suffix: 'Esperanza',
  error: []
}

In Spanish, it's normal to have a double (two) surnames, one from the father's side and one from the mother's side. When this is written using the SURNAME COMMA GIVEN_NAME format, it trips up the parser.

I haven't had a chance to look at the code to see why this might be the case.

Line 73 and Line 74

Names like "Von Miller" is considered as an invalid name because "Von" is identified as a prefix rather than a first name. Would be nice to either have an option to not use the list of prefixes or better detect prefix vs first names.

This library does not work for names that do not follow western naming convention.

This probably can be assumed by the use of "first name" and "last name" (as opposed to family name and given name) in the library, but it would still be helpful to point this out.

Examples:

var {parseFullName} = require("parse-full-name")

// "Tai" is the family name, "Hui Ying" is the given name
console.log(parseFullName('Tai Hui Ying'));

// Given name is "Ackbar", family name is "Sayid" (or more accurately, father's name as it translates to Son of Sayid)
console.log(parseFullName('Muhammed Ackbar bin Muhammed Sayid'));

// Some indigenous peoples have only one name, the library incorrecly identifies this as lastName
console.log(parseFullName('Alison'));

Thank you for this library. I really like the case-fixing that it provides.

When I call this library like parseFullName('steven'), the result is that steven is returned as the last name. This seems counterintuitive to me and should be returned as the first name.

I'm also encountering the same behaviour and wanted to see if the author/maintainers can discuss the rationale behind this design decision. The behaviour is easy enough to change, but I don't want to make my special case into the general case, because my case could be domain-specific. We work with student names, so in cases where the person who's providing the identity of the student isn't comfortable doing so, we don't make them supply a surname. Thus, in most cases if only a single name is supplied, we should be assuming that it's a given/first name.