Issue 1:
Feature request

add "hot module introspection"

as a feedback channel from browser to editor

situation in my code editor

class Class1 {constructor() {this.key1 = 'val1'}};
class Class2 {constructor() {this.key2 = 'val2'}};
obj1 = new Class1();
obj2 = new Class2();

obj1.k
// ^
// at this point i want "hot code completion" in my code editor
// so only "key1" is suggested, but not "key2"

// code introspection at runtime
Object.keys(obj1)
// = [ 'key1' ]

// the node.js shell can do it
obj1.k
// ^
// the tab-key does the right completion to "key1"

Ideal?

What is the expected behavior?

obj1.k
// ^
// at this point i want "hot code completion" in my code editor
// so only "key1" is suggested, but not "key2"

as far as i know

all code editors fail at this point of "dynamic code analysis"

the best they can offer is: key1 or key2

vscode and eclipse do this by default

vscode calls this "intellisense text suggestions"

but i dont want to be limited by "static code analysis"

when the program is started anyway, after every file change

Solution?

How should this be implemented in your opinion?

extend the "hot module replacement" system

to feed back "hot module introspection" data to the editor

this introspection-data can be sent over http

so the editor has a keep-alive connection

and is waiting for the server to push new introspection data

.... or use the browser as code editor, using CodeMirror

and show the program inside a frame, like on jsfiddle.net

[ the code completion function of codemirror seems broken to me ]

the data format should be optimized for machine-readability

for example by using length-prefixed lists and strings,

like in BSON, messagepack, python-pickle, EXI, flatbuffers, ....

in an ideal world, the javascript runtime does offer a fast way

to access the "internal representation" of the running program

limits

introspection requires a valid program,

so you must have a running "last version"

to provide introspection data for your not-running "current version"

potential problems

circular references must be detected and handled

like object.child.parent.child.parent.child....

related

recursive introspection in javascript

get inherited properties of javascript objects

VS Code to autocomplete JavaScript class 'this' properties automatically

-- "doesn't work too well if you bind things to the class at runtime"

the ahaa moment of hot reloading in clojurescript/figwheel, by bruce hauman

Why?

What is motivation or use case for adding/changing the behavior?

this allows for "zero knowledge programming"

let the machine do the boring-precise part of

"how did i call this property? where is it hidden?"

and focus on the creative-fuzzy part of

"let me just add something like ...."

this also makes it much easier to learn new libraries.

instead of depending on good documentation,

you can make full use of the existing introspection functions.

for "distant properties" who are hidden in child/parent objects,

you can browse a "map of properties", like a mind-map.

also, why not? : P

Are you willing to work on this yourself?

no, not today.

i hope that the "insider people" can solve this much faster than me

and i can avoid digging into unfamiliar projects

more keywords

code hinting, runtime analysis, dynamic analysis, runtime introspection, live object introspection, hierarchy of variable names, javascript object graph

Issue 2:
Bug report

What is the current behavior?

Many modules published to npm are using "auto" exports (https://rollupjs.org/guide/en#output-exports-exports, but there is also a popular babel plugin which adds this behaviour https://github.com/59naga/babel-plugin-add-module-exports#readme) which is supposed to ease interop with node (removing "pesky" .default for CJS consumers when there is only a default export in the module).

And with that depending on a package authored solely in CJS (which still is really common) which depends on a package authored using the mentioned "auto" mode is dangerous and broken.

Why? Because webpack is using the "module" entry from package.json (thus using real default export) without checking the requester module type (which is cjs here). CJS requester did not use a .default when requiring the package with auto mode, because from its perspective there was no such thing.

If the current behavior is a bug, please provide the steps to reproduce.

https://github.com/Andarist/webpack-module-entry-from-cjs-issue . Exported value should be "foobar42" instead of "foo[object Module]42"

What is the expected behavior?

Webpack should deopt (ignoring .mjs & "module") its requiring behaviour based on the requester type.

Other relevant information:

webpack version: latest

Node.js version: irrelevant

Operating System: irrelevant

Additional tools: irrelevant

Mentioning rollup team as probably its the tool outputting the most auto mode libraries ( @lukastaegert @guybedford ) and @developit (who I think might be interested in the discussion).