Ported to Typescript #22

mattes3 · 2019-07-12T07:58:46Z

This solves #18.

...will convert to Webpack, later, because rollup seems to have problems with exporting the *.d.ts file from Typescript.

...now we have several build results, i.e. one UMD module, one CommonJS module and one ES module. Adjusted README to new output path names.

IceCreamYou

First of all, this is great - thanks for doing this. I think only very small changes stand between the current state and merging this PR.

I do have some higher level feedback / questions:

I understand why individual developers might want to use yarn, but I don't see a strong reason to force people to use it. Everyone should have npm and they have essentially the same features and performance these days. Alternatively, yarn could be installed as a dev dependency so people can just run npx yarn.
It would be useful to add some guidance to the README regarding how non-TypeScript users could import only part of the project. Alternatively, it'd be nice if the build process emitted separate files for each source file (in addition to a combined file) so that non-TypeScript users could use parts of the project without needing a TypeScript compiler / bundler.
It seems that build files are omitted from this PR; how would you then propose that the demo remain functional, and how would you propose doing releases of this library? (Understanding this is a merge blocker.)
It looks like source maps aren't emitted? That seems like a significant regression, probably a merge blocker. Should be a small change to add that.
Is the idea with ESM that a consumer will use Rollup or something like it, with their own custom config, to consume the imports, bundle everything up, and eventually minify it? As is, the UMD version is a much smaller file than the ESM version.

IceCreamYou · 2019-07-15T07:05:40Z

.gitignore

@@ -1,2 +1,3 @@
 node_modules
 package-lock.json
+dist/


Missing trailing newline?

First of all, this is great - thanks for doing this. I think only very small changes stand between the current state and merging this PR.

Cool.

I do have some higher level feedback / questions:

I understand why individual developers might want to use yarn, but I don't see a strong reason to force people to use it. Everyone should have npm and they have essentially the same features and performance these days. Alternatively, yarn could be installed as a dev dependency so people can just run npx yarn.

OK, I've ported it back to npm.

It would be useful to add some guidance to the README regarding how non-TypeScript users could import only part of the project. Alternatively, it'd be nice if the build process emitted separate files for each source file (in addition to a combined file) so that non-TypeScript users could use parts of the project without needing a TypeScript compiler / bundler.

I will have to think about this.

It seems that build files are omitted from this PR; how would you then propose that the demo remain functional, and how would you propose doing releases of this library? (Understanding this is a merge blocker.)

The demo simply runs as before. I changed almost nothing in the demo files. Just try

npm run build npm run serve

It looks like source maps aren't emitted? That seems like a significant regression, probably a merge blocker. Should be a small change to add that.

Yes, I'll re-enable them.

Is the idea with ESM that a consumer will use Rollup or something like it, with their own custom config, to consume the imports, bundle everything up, and eventually minify it? As is, the UMD version is a much smaller file than the ESM version.

Exactly. People who use modules will have their own bundler, like webpack or similar. They will run their own minifier, of course.

Re-enabled sourcemaps, now.

The demo simply runs as before. I changed almost nothing in the demo files. Just try
npm run build
npm run serve

Since the artifacts produced by npm run build are not tracked by git, the demo will not run on GitHub Pages. (Previously the artifacts were tracked in the build folder, whereas with this PR they're in the dist folder which is in .gitignore.) Similarly, I think library releases would require an additional packaging step so that consumers would not have to build this project in order to make use of it as a dependency.

src/generators.ts

src/influences.ts

src/main.ts

IceCreamYou · 2019-07-22T05:51:30Z

src/basicTypes.ts

+
+export type HeightmapFunction = ((g: Vector3[], options: TerrainOptions) => void);
+
+export interface TerrainOptions {


This interface makes all properties required, but only a few are required for each function that uses TerrainOptions. A couple places do use Pick or Partial, but many uses don't. In no case are all properties required, and in some cases all properties are optional.

I guess I will need you help, here. I wasn't able to always figure out if the options were needed or not. Sometimes, when I used too much Pick or Partial, I ran into a dead end because I could not make it work. Most of the places where TerrainOptions is used are called from Terrain() anyway so that the options all have default values.

Can you help here, please?

If you change export interface TerrainOptions { to export type TerrainOptions = Partial<{ and recompile, you will get 164 errors, each listing a property that should be available. For example, GaussianBoxBlur will complain that it's missing options.xSegments and options.ySegments.

I acknowledge that this is a substantial update. As a compromise, how about we just make the most commonly used properties required?

export interface TerrainOptions { after?: ((v: Vector3[], options: TerrainOptions) => void) | null; easing?: EasingFunction; heightmap?: HTMLCanvasElement | ImageBitmap | HeightmapFunction; material?: Material | null; maxHeight: number; minHeight: number; optimization?: Optimization; frequency: number; steps?: number; stretch?: boolean; turbulent?: boolean; useBufferGeometry?: boolean; xSegments: number; xSize: number; ySegments: number; ySize: number; }

src/scatter.ts

tsconfig.json

IceCreamYou · 2019-07-22T06:45:13Z

src/main.ts

+export * from './analysis';
+export * from './basicTypes';
+export * from './brownian';
+export * from './core';


THREE.Terrain.Terrain is awkward, and unnecessary I think. It could potentially be improved with something like this (untested):

import * as T from './terrain'; import { Analyze } from './analysis'; import { Brownian } from './brownian'; // ... export function Terrain(...args) { return T.Terrain(...args); } export namespace Terrain { export const Analyze = Analyze; export const Brownian = Brownian; // ... }

I'd be interested in alternatives you may have considered.

Hmmm ... not sure about this one. Microsoft wrote a doc page that discourages using modules and namespaces in the same file. I tried similar stuff in the past and I always ran into some kind of absolute weirdness. It really seems as if Typescript does not like mixing up modules and namespaces. However, it was too long ago so that I do not remember what happened exactly.

As far as I'm aware, the whole purpose of namespaces is to merge declarations like this. Nothing on the page you linked that I can see warns against combining them. Regardless, I don't care so much how it's accomplished, I just think Terrain.Terrain is awkward and it should be possible to construct an API signature that doesn't repeat itself 🙂

package.json

IceCreamYou · 2019-08-15T21:03:25Z

@mattes3 are you planning on making any updates?

mattes3 · 2019-08-16T07:10:57Z

Oops, I completely missed your feedback because I'm currently under a pile of other things. Will have a look at this over the weekend.

IceCreamYou · 2019-08-16T21:18:44Z

No worries

mattes3 · 2019-08-19T21:05:02Z

OK, so most of this stuff is done, some things are still remaining. I'll have to get some sleep, first. Maybe you can have a look and tell me what you think.
Cheers,
Matthias

IceCreamYou · 2019-08-22T23:24:15Z

Responded to some threads - the other changes look good. Thanks for the updates. As an FYI, I am going on vacation tomorrow for about 10 days, so I may not be able to answer questions during that time.

mattes3 · 2021-01-20T10:44:23Z

I cannot proceed with this. Does anyone like to take over the work?

k2xl · 2022-03-24T20:39:43Z

@IceCreamYou are you able to merge this?

IceCreamYou · 2022-03-25T02:02:44Z

No, this is not in a releasable state. The biggest issue is that the new design does not support non-TypeScript users.

mattes3 · 2022-03-25T10:36:34Z

No, this is not in a releasable state. The biggest issue is that the new design does not support non-TypeScript users.

As far as I remember, this is not true. I invested a lot of time in 2019 to make sure that it still runs in plain JS.

IceCreamYou · 2022-03-26T01:39:49Z

Sorry, I was imprecise. The biggest problem is in the packaging:

Since the artifacts produced by npm run build are not tracked by git, the demo will not run on GitHub Pages. (Previously the artifacts were tracked in the build folder, whereas with this PR they're in the dist folder which is in .gitignore.) Similarly, I think library releases would require an additional packaging step so that consumers would not have to build this project in order to make use of it as a dependency.

In other words, sure, consumers can use the library without TypeScript... but only if they use TypeScript to compile it first.

There are a couple other smaller things I'd like to see addressed as well, most notably the API signature change to THREE.Terrain.Terrain since that would require another major version bump to fix if this was merged as is.

Matthias Bohlen added 6 commits July 7, 2019 10:31

Converted to Typescript and rollup...

181edd3

...will convert to Webpack, later, because rollup seems to have problems with exporting the *.d.ts file from Typescript.

First running version after Typescript conversion.

41999dd

Added forgotten imports.

614e727

Removed redundant default value checking.

0bad10d

Made levels or glsl optional, for base texture.

3601996

Added linting, removed bower because...

c36e3e9

...now we have several build results, i.e. one UMD module, one CommonJS module and one ES module. Adjusted README to new output path names.

IceCreamYou reviewed Jul 22, 2019

View reviewed changes

Matthias Bohlen added 8 commits August 19, 2019 22:01

Ported back from yarn to npm.

fe6986c

Minor cosmetics.

edae780

Added trailing newline.

b23c2d5

Added return type annotation.

4778a78

Moved interface before doc block.

63c10a0

Make sure that build does not fail if dist does not exist, yet.

f8bf90c

Re-enabled sourcemaps.

c717d94

Spread function now has access to the face and its coordinates.

200072a

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Ported to Typescript #22

Ported to Typescript #22

mattes3 commented Jul 12, 2019

IceCreamYou left a comment

IceCreamYou Jul 15, 2019

mattes3 Aug 19, 2019

mattes3 Aug 19, 2019

IceCreamYou Aug 22, 2019

IceCreamYou Jul 22, 2019

mattes3 Aug 19, 2019

IceCreamYou Aug 22, 2019

IceCreamYou Jul 22, 2019

mattes3 Aug 19, 2019

IceCreamYou Aug 22, 2019

IceCreamYou commented Aug 15, 2019

mattes3 commented Aug 16, 2019

IceCreamYou commented Aug 16, 2019

mattes3 commented Aug 19, 2019

IceCreamYou commented Aug 22, 2019

mattes3 commented Jan 20, 2021

k2xl commented Mar 24, 2022

IceCreamYou commented Mar 25, 2022

mattes3 commented Mar 25, 2022

IceCreamYou commented Mar 26, 2022


		export type HeightmapFunction = ((g: Vector3[], options: TerrainOptions) => void);

		export interface TerrainOptions {

Ported to Typescript #22

Are you sure you want to change the base?

Ported to Typescript #22

Conversation

mattes3 commented Jul 12, 2019

IceCreamYou left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

IceCreamYou commented Aug 15, 2019

mattes3 commented Aug 16, 2019

IceCreamYou commented Aug 16, 2019

mattes3 commented Aug 19, 2019

IceCreamYou commented Aug 22, 2019

mattes3 commented Jan 20, 2021

k2xl commented Mar 24, 2022

IceCreamYou commented Mar 25, 2022

mattes3 commented Mar 25, 2022

IceCreamYou commented Mar 26, 2022