gopherjs
gopherjs copied to clipboard
add --analyze for dump pkgs info
gopherjs build --analyze for print simply pkg info. --anylize --json print pkgs json info.
for https://github.com/goplusjs/gopherjs/pull/3
> gopherjs --analyze hello
<Size> <ImportPath>
56914 $prelude
6947 github.com/gopherjs/gopherjs/js
446 internal/cpu
879 internal/bytealg
454 runtime/internal/sys
8489 runtime
1055 internal/unsafeheader
119993 internal/reflectlite
1619 errors
4665 math/bits
2106 math
15438 unicode/utf8
89933 strconv
1017 internal/race
457 runtime/internal/atomic
2975 sync/atomic
37844 sync
441 unicode
287744 reflect
12061 sort
21539 internal/fmtsort
10469 io
890 internal/oserror
115310 syscall
2377 github.com/gopherjs/gopherjs/nosync
165010 time
99944 internal/poll
631 internal/syscall/execenv
893 internal/syscall/unix
2309 internal/testlog
1020 path
8958 io/fs
81367 os
126487 fmt
2788 github.com/goplusjs/js_demo/em_struct
--analyze --json for print pkgs json format info.
type PkgInfo struct {
Name string `json:"Name"`
ImportPath string `json:"ImportPath,omitempty"`
Imports []string `json:"Imports,omitempty"`
Size int64 `json:"Size"`
}
> gopherjs build --analyze -json hello
[
{
"Name": "$prelude",
"Size": 56914
},
{
"Name": "js",
"ImportPath": "github.com/gopherjs/gopherjs/js",
"Size": 6947
},
{
"Name": "cpu",
"ImportPath": "internal/cpu",
"Size": 446
},
。。。
]
I suppose that would work, although it would be better to output into a file on disk, rather than stdout. The way it currently is, the JSON data would get mixed with all the other outputs GopherJS may produce and separating them would be tricky.
I suppose that would work, although it would be better to output into a file on disk, rather than stdout. The way it currently is, the JSON data would get mixed with all the other outputs GopherJS may produce and separating them would be tricky.
current start line with "anylize pkg: xxx"
Sure, not saying it's not doable, only that it feels a bit inelegant.
There's also another option, which is to make a better use of the source map GopherJS produces, add all relevant information into it and use it with any sourcemap visualizer tool like https://github.com/danvk/source-map-explorer. Having thought about it a bunch I increasingly feel like this would be both more elegant and versatile solution to the problem than this PR or mine.
That said, any solution that exists and works is usually better than the most elegant solution that doesn't exist at all :)
Sure, not saying it's not doable, only that it feels a bit inelegant.
There's also another option, which is to make a better use of the source map GopherJS produces, add all relevant information into it and use it with any sourcemap visualizer tool like https://github.com/danvk/source-map-explorer. Having thought about it a bunch I increasingly feel like this would be both more elegant and versatile solution to the problem than this PR or mine.
That said, any solution that exists and works is usually better than the most elegant solution that doesn't exist at all :)
modify --anylize dump simply info, --anylize --json dump json info.