ESNext support about harp.gl

[ReeRichard]

Ok understood. I see that something like webpack makes sense, I thought I will loose ability to properly debug this thing when using webpack but I will give it a try.

For now what works is that I built harp.gl with target for esnext import it as usual but then remove the import as a post build step and replace it by referencing the bundled version. This way I can use the typed version during development and the bundled during run-time.
A little bit hacky but good for now. So this has no high priority as it works quite well.

Thank you again for this neat library.

[nzjony]

@ReeRichard , thanks for creating this issue, I see that @CraigBerlin has created an internal issue on our side. We will prioritize and hopefully we can get someone to look into it soon!

[zbigg]

@ReeRichard Could you please tell what exactly doesn't work for you?
In particular, how do you bundle, what is your tsconfig.json ?
(Repo with minimal repro would be awesome).

I am not aware of any fundamental problems that make our packages incompatible with TS esnext target.

[ReeRichard]

Hi, thank you for your support.

I probably confuse some things here since I'm pretty new to Typescript/Module Resolution Ecosystem. The problem is more about how java script is loaded/included. I use Lit-element as the main system for rendering components. And every module is loaded through import * as XY from Z instead of the require(filename) that is found anywhere in the harp.gl code and transpiled version. The require method is not supposed to work anymore as it looks like with the latest target such as esnext?

This is how my tsconfig.json looks like

{
	"compileOnSave": true,
	"compilerOptions": {
		"baseUrl": "../",
		"declaration": true,
		"rootDir": "./",
		"outDir": "../build",
		"target": "esnext",
		"module": "esnext",
		"moduleResolution": "node",
		"alwaysStrict": true,
		"allowJs": false,
		"strictBindCallApply": true,
		"strictFunctionTypes": true,
		"strictPropertyInitialization": true,
		"strictNullChecks": true,
		"experimentalDecorators": true,
		"emitDecoratorMetadata": true,
		"noFallthroughCasesInSwitch": true,
		"noImplicitAny": true,
		"noImplicitReturns": true,
		"noUnusedLocals": true,
		"noImplicitThis": true,
		"noUnusedParameters": false,
		"removeComments": false,
		"skipLibCheck": true,
		"preserveConstEnums": true,
		"sourceMap": true,
		"pretty": true,
		"lib": [
			"esnext",
			"dom"
		]
	},
	"include": [
		"../src/**/*.ts"
	],
	"exclude": [
		"node_modules"
	]
}

[zbigg]

require(filename) that is found anywhere in the harp.gl code

Yeah, just as I've expected. Yes, we have few require leftovers caused by problems with build environment, hopefully we can fix them soon.
Until now, the only workaround is to bundle our code with webpack which support mixed require & import in sources or use harp.js in already bundled form - https://github.com/heremaps/harp.gl/tree/master/%40here/harp.gl, but this has some disadvantages like lack of typings.

require method not supposed to work anymore as it looks like with the latest target such as esnext?

It never worked directly, it was just bundler responsibility to handle this function in special way. I assume that you don't use any bundler, that's why you encounter problems. It's just our fault that some of use assumed that everyone uses bundler and that it's webpack :)

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.