Вбудовані модулі Мавки

[ossenjoyer]

Як ви ставитеся до впровадження в Мавку модулів, які імпортуються під час інтерпретації файлу, без потреби попереднього імпорту в файлі, який запускається? Це вже було реалізовано @dkostmii, але було б непогано додати runtime модулі в основний репозиторій Мавки.

[kohutd]

Впринципі чому ні, але мабуть краще назвати startup modules і придумати українську назву

[dkostmii]

Впринципі чому ні, але мабуть краще назвати startup modules і придумати українську назву

Перейменував папку runtime-modules на startup-modules у цьому комміті

[ossenjoyer]

якщо у нас це називатиметься startup modules, то логічно припустити, що українська версія буде звучати, як "модулі запуску", але можна просто назвати це вбудованими модулями

[dkostmii]

Перед додаванням коду в основний репозиторій необхідно провести аудит наступного коду:

• файл src/bin/mavka.js (починаючи з рядку 177)
• файл src/loaders/fileLoader.js (рядки 53-82)

Необхідно прибрати зайві операції та переконатись, що не буде непередбачуваної поведінки.

[kohutd]

@dkostmii зробіть PR з вашими змінами, це дозволить зручніше оглянути і виділити конкретні зміни, які ви пропонуєте

[dkostmii]

PR знаходиться ось тут #28

[kohutd]

PR прийнято і випущено у 0.10.21 версії

UPD: Хоча скажу чесно, мені не дуже подобається як воно імплементовано. Перезапис контексту і копіювання vars треба прибрати.

[kohutd]

Також треба продумати можливість завантаження цих модулів в інших середовищах типу грального майданчика

[dkostmii]

PR прийнято і випущено у 0.10.21 версії

UPD: Хоча скажу чесно, мені не дуже подобається як воно імплементовано. Перезапис контексту і копіювання vars треба прибрати.

Імплементацію змінено у #29

[ossenjoyer]

було б непогано додати в документацію пункт про вбудовані модулі

[ossenjoyer]

Тепер, якщо питання з вбудованими модулями вирішено, то які модулі вбудовуватимемо?

[dkostmii]

Тепер, якщо питання з вбудованими модулями вирішено, то які модулі вбудовуватимемо?

Якщо вже використовуємо імперативний конструктор у Даті, то треба визначити, які є типи даних, які вимагають валідації параметрів конструктора.

[dkostmii]

Також постає питання, чи ці вбудовані модулі будуть містити щось, що б мало увійти до стандартної теки.

[ossenjoyer]

Також постає питання, чи ці вбудовані модулі будуть містити щось, що б мало увійти до стандартної теки.

А як щодо того, щоб створити issue, де розробники можуть запропонувати свій модуль у якості кандидата на пост вбудованого модулю?

[dkostmii]

Також постає питання, чи ці вбудовані модулі будуть містити щось, що б мало увійти до стандартної теки.

А як щодо того, щоб створити issue, де розробники можуть запропонувати свій модуль у якості кандидата на пост вбудованого модулю?

Цілком гарна ідея, у стандартній теці, наскільки я пам'ятаю уже є кандидати роль вбудованих модулів.

Щодо ФС, було б теж добре, але потрібно мати якесь рішення для браузерів (яке дає змогу прочитати та зберегти файл).

[ossenjoyer]

Також постає питання, чи ці вбудовані модулі будуть містити щось, що б мало увійти до стандартної теки.

А як щодо того, щоб створити issue, де розробники можуть запропонувати свій модуль у якості кандидата на пост вбудованого модулю?

Цілком гарна ідея, у стандартній теці, наскільки я пам'ятаю уже є кандидати роль вбудованих модулів.

Щодо ФС, було б теж добре, але потрібно мати якесь рішення для браузерів (яке дає змогу прочитати та зберегти файл).

Не думаю, що на гральному майданчику треба робота з файловою системою. До того ж, це може бути не зовсім безпечно для сервісу

[dkostmii]

Також постає питання, чи ці вбудовані модулі будуть містити щось, що б мало увійти до стандартної теки.

А як щодо того, щоб створити issue, де розробники можуть запропонувати свій модуль у якості кандидата на пост вбудованого модулю?

Цілком гарна ідея, у стандартній теці, наскільки я пам'ятаю уже є кандидати роль вбудованих модулів.

Щодо ФС, було б теж добре, але потрібно мати якесь рішення для браузерів (яке дає змогу прочитати та зберегти файл).

Не думаю, що на гральному майданчику треба робота з файловою системою. До того ж, це може бути не зовсім безпечно для сервісу

Ну в такому разі необхідно якимось чином зазначити, що такий модуль несумісний з браузерним рушієм.

[ossenjoyer]

Також постає питання, чи ці вбудовані модулі будуть містити щось, що б мало увійти до стандартної теки.

А як щодо того, щоб створити issue, де розробники можуть запропонувати свій модуль у якості кандидата на пост вбудованого модулю?

Цілком гарна ідея, у стандартній теці, наскільки я пам'ятаю уже є кандидати роль вбудованих модулів.

Щодо ФС, було б теж добре, але потрібно мати якесь рішення для браузерів (яке дає змогу прочитати та зберегти файл).

Не думаю, що на гральному майданчику треба робота з файловою системою. До того ж, це може бути не зовсім безпечно для сервісу

Ну в такому разі необхідно якимось чином зазначити, що такий модуль несумісний з браузерним рушієм.

Пропоную додати якийсь ignoreModulesForPlayground, або просто їх не завантажувати

[dkostmii]

Також постає питання, чи ці вбудовані модулі будуть містити щось, що б мало увійти до стандартної теки.

А як щодо того, щоб створити issue, де розробники можуть запропонувати свій модуль у якості кандидата на пост вбудованого модулю?

Цілком гарна ідея, у стандартній теці, наскільки я пам'ятаю уже є кандидати роль вбудованих модулів.

Щодо ФС, було б теж добре, але потрібно мати якесь рішення для браузерів (яке дає змогу прочитати та зберегти файл).

Не думаю, що на гральному майданчику треба робота з файловою системою. До того ж, це може бути не зовсім безпечно для сервісу

Ну в такому разі необхідно якимось чином зазначити, що такий модуль несумісний з браузерним рушієм.

Пропоную якийсь ignoreModulesForPlayground, або просто їх не завантажувати

Потрібно застосувати принцип three shaking. Модуль самостійно визначає, чи він несумісний, прикладом може бути декларація змінної:

__несумісно_з_браузером__ = так

Або ж просто коментарем, аби не писати додаткове так

[ossenjoyer]

Також постає питання, чи ці вбудовані модулі будуть містити щось, що б мало увійти до стандартної теки.

А як щодо того, щоб створити issue, де розробники можуть запропонувати свій модуль у якості кандидата на пост вбудованого модулю?

Цілком гарна ідея, у стандартній теці, наскільки я пам'ятаю уже є кандидати роль вбудованих модулів.

Щодо ФС, було б теж добре, але потрібно мати якесь рішення для браузерів (яке дає змогу прочитати та зберегти файл).

Не думаю, що на гральному майданчику треба робота з файловою системою. До того ж, це може бути не зовсім безпечно для сервісу

Ну в такому разі необхідно якимось чином зазначити, що такий модуль несумісний з браузерним рушієм.

Пропоную якийсь ignoreModulesForPlayground, або просто їх не завантажувати

Потрібно застосувати принцип three shaking. Модуль самостійно визначає, чи він несумісний, прикладом може бути декларація змінної:

__несумісно_з_браузером__ = так

Або ж просто коментарем, аби не писати додаткове так

Тобто кожен розробник має вказати на самому початку коду модуля змінну, чи коментар про те, що модуль несумісний з гральних майданчиком(браузером)?

[dkostmii]

Також постає питання, чи ці вбудовані модулі будуть містити щось, що б мало увійти до стандартної теки.

А як щодо того, щоб створити issue, де розробники можуть запропонувати свій модуль у якості кандидата на пост вбудованого модулю?

Цілком гарна ідея, у стандартній теці, наскільки я пам'ятаю уже є кандидати роль вбудованих модулів.

Щодо ФС, було б теж добре, але потрібно мати якесь рішення для браузерів (яке дає змогу прочитати та зберегти файл).

Не думаю, що на гральному майданчику треба робота з файловою системою. До того ж, це може бути не зовсім безпечно для сервісу

Ну в такому разі необхідно якимось чином зазначити, що такий модуль несумісний з браузерним рушієм.

Пропоную якийсь ignoreModulesForPlayground, або просто їх не завантажувати

Потрібно застосувати принцип three shaking. Модуль самостійно визначає, чи він несумісний, прикладом може бути декларація змінної:

__несумісно_з_браузером__ = так

Або ж просто коментарем, аби не писати додаткове так

Тобто кожен розробник має вказати на самому початку змінну, чи коментар про те, що модуль несумісний з гральних майданчиком(браузером)?

Річ в тім, що пакет NPM Мавки може використовуватись будь-де.

І якщо ми просто відфільтруємо ці модулі у src/startup-modules/index.js, то консументи пакету не отримають необхідних модулів, навіть якщо вони на базі NodeJS.

Також це дозволить у разі чого перенести ці модулі у інше середовище, яке одразу знатиме, що модуль не для браузера. Бо властивості кокретного модуля знаходяться у модулі :)

[dkostmii]

У випадку браузера, консумент отримує інформацію, що модуль недоступний, але коду модуля не отримує.

[ossenjoyer]

Цей крок дозволить фільтрувати не тільки вбудовані модулі, а й модулі з мережі. Що ж, доволі непогана ідея.

[ossenjoyer]

Підсумуємо: для того, щоб гральний майданчик не ламався від не підтримуваних модулів, розробник має вказати на самому початку коду або

;; __не_сумісний_з_браузером__

або

__несумісний_з_браузером__ = так

[ossenjoyer]

Залишилось тільки те, щоб розробники дотримувались цього правила під час розробки власних модулів для мавки

[kohutd]

Мабуть краще __сумісний_з_браузером__ зі стандартним значенням так