Update Parcel to a stable release

[thewilkybarkid]

Parcel has had its first release candidate released; this includes changes such as changing the JavaScript compiler (actually in beta 3).

After an initial test, the project as-in doesn't build.

[thewilkybarkid]

Usage of the ORM currently has a lot of circular dependencies (where two entities depend on each other). The JS changes in Parcel seem to fail when building: Cannot access 'Community' before initialization

[thewilkybarkid]

parcel-bundler/parcel#6694 might help.

[thewilkybarkid]

Seems like parcel-bundler/parcel#7053 has fixed one of the main problems (variables declared in the wrong order). It almost compiles now, but there's one enum that becomes misnamed (extracting it into its own module gets around the problem). parcel-bundler/parcel#7057 might be the fix for this (I'm not sure what the PR does, but the test case involves enums.).

[thewilkybarkid]

Parcel 2.0.0 has now been released, but the app still doesn't build.

[thewilkybarkid]

I've tried no end of combinations, but I can't just get it to work, and there's so many tools using magic I can't understand what's going on properly.

When using @parcel/transformer-typescript-tsc things seem to be generated in the wrong order ("Cannot access ... before initialization"). When not, metadata to do with the ORM entity decorators seem to be missing. When adding in Babel configuration to try and sort that out, it's generated in the wrong order again. 🤷‍♂️

[thewilkybarkid]

Trying to resolve the order issue in parcel-bundler/parcel#6676 (comment).

[thewilkybarkid]

I've managed to reproduce the Parcel problem and open a PR: parcel-bundler/parcel#7293.

[thewilkybarkid]

In order to move this forward, we should remove the decorators and use EntitySchema instead.

#398 (comment) needs to be addressed though, as there is some code reliant on the use of decorators.

[thewilkybarkid]

I'm currently struggling to get EntitySchema to work with Parcel's scope hoisting as classes are renamed, whereas the ORM relies on them being unchanged (so they're different at runtime). This wasn't a problem with the decorators as they were processed by TSC before Parcel would try to change them(?). Options are probably either to disable Parcel's scope hoisting/optimisation or define them explicitly.

[thewilkybarkid]

define them explicitly

This didn't work, the types seemingly allow for both a class and a name to be set, but the latter is ignored and the name of the class itself continues to be used.

I also looked at using types rather than classes, which works but you have to declare types everywhere (since you're just referring to them by a string).

Feels like the most pragmatic approach now is to stop Parcel from mangling the names.

[KillerCodeMonkey]

hey gordon shumway :D. (nice avatar)

i saw your issues at parcel to use parcel v2.

I am using typeorm with sqlite in an electron app.
everything worked with parcel v2 beta3.1 but not with the final version.

I got it working by:

• deactivating scopeHoisting and optimizations.
• to avoid circular deps in entities - import you entities as with "type" and use relations as strings, e.g.

import type { person } from '../entities/person'

@Entity({ name: 'family' })
export class Family {
  @PrimaryGeneratedColumn()
  id: number

  // One family holds multiple patients
  @OneToMany('Person', 'family', { eager: true })
  patients: Person[]

  @CreateDateColumn()
  createdAt: Date

  @UpdateDateColumn()
  updatedAt: Date
}

PS: in the beta i needed to set a specific entity name, because parcels scopeHosting transformed the name of the class.