verion 1.0.6 error "* txml/txml in ./node_modules/ol/node_modules/geotiff/src/geotiffimage.js"

[tian16300]

system windows install geotiff@1.0.6 error "* txml/txml in ./node_modules/ol/node_modules/geotiff/src/geotiffimage.js"

[pzdralewicz]

got the same issue after clean install. might be related with #240

[shayantabrizi]

Similar problem for me.

[constantinius]

@tian16300 @shayantabrizi @pzdralewicz On OSX I cannot reproduce the problem. Is there more information to this error?

[pzdralewicz]

@constantinius unfortunatelly not, the message:

Module not found: Can't resolve 'txml/txml' in '/app/node_modules/geotiff /src'

is all i get from the dev server. I will quickly add ol back to my project to provide exact message

EDIT:

./node_modules/geotiff/src/geotiffimage.js Module not found: Can't resolve 'txml/txml' in '/app/node_modules/geotiff/src'

[shayantabrizi]

ERROR in [REDACTED]/node_modules/geotiff/src/geotiffimage.js [REDACTED]: Module not found: Error: Can't resolve 'txml/txml' in '[REDACTED]/node_modules/geotiff/src' [REDACTED]: @ [REDACTED]/node_modules/geotiff/src/geotiffimage.js 4:0-34 778:19-24 [REDACTED]: @ [REDACTED]/node_modules/geotiff/src/geotiff.js [REDACTED]: @ [REDACTED]/node_modules/ol/source/GeoTIFF.js [REDACTED]: @ [REDACTED]/node_modules/ol/source.js

[zheyi420]

win10, "ol": "^6.1.0", I have the same problem,

npm uninstall geotiff and then npm install geotiff@1.0.5 project can run.

[constantinius]

This seems to be related to #234

[manzt]

Any information on what dev server is used? #234 uses txml package.json "exports" alias to only load the part of the module that doesn't rely on any node builtin dependencies.

Package exports are a node standard that is used by the node resolver as well as most modern bundlers

• Node: https://nodejs.org/api/packages.html
• Webpack 5: https://webpack.js.org/guides/package-exports/

It is also recognized by vite, esbuild, and parcel 2.

However, I don't think that this feature is supported in legacy webpack. If you are using webpack<5, I would suggest adding:

module.exports = {
  //...
  resolve: {
     'txml/txml': 'txml/dist/txml'
  },
};

[jcrandle]

Ran into this as well after deleting my node_modules and doing a new install.

In node_modules/geotiff/src/geotiffimage.js

I changed the import on line 4 to:

import { parse } from 'txml';

And it works for me.

[manzt]

The issue is that top level txml imports txml/transfromStream.js which has a dependency on node-builtins and is not used in geotiff.js. This means that any bundler that needs to resolve txml will also need to know how to handle the node dependency through2, that txml/transformStream relies on. This causes issues.

Since this module is not used at all in geotiff.js, package exports allow for the safe import of a browser-compatible module and avoiding the module resolution for an unused node-specific feature that requires a polyfill.

Out of curiosity, does changing the import to txml/dist/txml work as well @jcrandle?

[ahocevar]

I just submitted #243, which should fix the issue.

[JabariZheng]

I just submitted #243, which should fix the issue.

When will the new version be released

[mmomtchev]

@ahocevar please, don't use an alias, it wreaks havoc in TypeScript projects where I have to add this alias to the corresponding tsconfig.json:

"paths": {
    "txml/txml": ["node_modules/txml/dist/txml"]
}

It is an ugly solution.

The author made a weird decision when he published this package, we are stuck with it, import it from dist, there is nothing to be done

[mmomtchev]

@ahocevar please disregard this comment, I installed from git+https://github.com/ahocevar/geotiff.js.git#fix-txml and I can confirm that it works with TypeScript, I had missed the modification of the import statement

[hescgis]

win10, "ol": "^6.1.0", I have the same problem,

npm uninstall geotiff and then npm install geotiff@1.0.5 project can run. I still can not solve this problem by using this method,any good idea ?

[mmomtchev]

@ahocevar webpack 5 doesn't like it - it expects to find txml in node_modules/geotiff/node_modules/txml

[manzt]

Hello all, I have created a gist bundling geotiff with many bundlers. With near-zero configuration, v1.0.6 supports esbuild, vite, rollup, webpack5, parcel2, and parcel1. It also runs directly in nodejs via cjs and esm imports. The challenge here seems to be webpack<5.

However, if we change the import in the source to txml, only webpack v4 and parcel1 will work out of the box correctly. In addition, bundles end up including txml/transfromStream (unused by geotiff!) ends up in the final bundle and includes a large polyfill for node-streams + Buffer. I am still trying to think of other tricks help accommodate all use cases, but I wanted to share the motivation around using the txml/txml import. As suggested above, the fix for webpack v4 should be to add a resolve.alias.

[ahocevar]

@mmomtchev node_modules/geotiff/node_modules/txml should be exactly the location where txml will be available, and I was able to verify this. Where do you see this not working?

[mmomtchev]

@ahocevar Not if npm deduped it - it will be there only if you have several versions of txml installed

[ahocevar]

@manzt The "browser" field in package.json should be used to solve these browser issue. When geotiff.js is used in as a dependency, like in ol. It is not practial for users of a library to deal with specifics of its dependencies, and to my knowledge, the "browser" field is respected by all major bundlers.

[mmomtchev]

Fixing this in geotiff.js will be very difficult - txml combines absolutely all of the touchy mechanics - ESM/CJS, browser/Node and the useless separate /dist directory - can't we get the author to back down at least on /dist? Also - he probably doesn't need an mjs, maybe type: module would be enough

[ahocevar]

If this can be improved in txml, then even better. I do see the problem you mentioned about pointing the alias to ./node_modules/txml/dist/txml.

[DanielJDufour]

For your consideration, I submitted https://github.com/geotiffjs/geotiff.js/pull/245. Basically, I've struggled with this bundling issue with other libraries as well, so I created an (even tinier) XML parsing library. It doesn't have as many features as txml, but it seems that our requirements are really just limited to parsing just the GDAL Metadata XML file. It is a newer library (no stars), but I do use it in a couple projects, including get-epsg-code and aux-xml. Also, happy to move xml-utils to a shared org if that matters. Either way, appreciate the consideration. Thank you :-)

[ahocevar]

245 is a very pragmatic solution, and because I had not ssen it before I updated #243 to alias txml correctly, which should address @mmomtchev's concern, choices are plenty now for the maintainer.

[constantinius]

This is fixed in v1.0.8 where txml is replaced.